Wireless spread spectrum communication platform using dynamically reconfigurable logic

ABSTRACT

A wireless spread spectrum communication platform for processing a communication signal is disclosed herein. The wireless communication platform includes a first computing element, a second computing element, and a reconfigurable interconnect. The first computing element is coupled to the second computing element via the reconfigurable interconnect. A design configuration of the first computing element is heterogeneous with respect to a design configuration of the second computing element. The reconfigurable interconnect has an uncommitted architecture, thereby allowing it to be configured by an outside source to couple portions of the first reconfigurable interconnect with portions of the second reconfigurable interconnect in a variety of combinations. The first computing element, the second computing element, and the reconfigurable interconnect operable to perform discrete functions suitable for processing of the communication signal.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to the provisional patent applicationwith the following Serial Number: 60/178,828 filed on Jan. 28, 2000.

MICROFICHE APPENDIX

A microfiche appendix entitled “Appendix B, Computer ProgramInstructions,” is included in the present application. The microficheappendix includes 1 microfiche card.

TECHNICAL FIELD

The present claimed invention relates to the field of wirelesscommunication. In particular, the present claimed invention relates toan apparatus and a method for processing digital signals in a wirelessspread spectrum communication system.

BACKGROUND ART

Wireless communication has extensive applications in consumer andbusiness markets. Among the many spread spectrum communicationapplications/systems are: fixed wireless, unlicensed (FCC) wireless,local area network (LAN), cordless telephony, personal base station,telemetry, mobile wireless, and other digital data processingapplications. While each of these applications utilizes spread spectrumcommunications, they generally utilize unique and incompatible protocolsfor various signal processing operations, e.g., encoding, modulation,demodulation, and decoding, etc. These unique and incompatible protocolsmay require unique hardware, software, and methodologies for thecommunication protocol. This practice can be costly in terms of design,testing, manufacturing, and infrastructure resources. As a result, aneed arises to overcome the limitations associated with the variedhardware, software, and methodology for processing digital signals ineach of the varied spread spectrum wireless applications.

In contrast to the hardware and algorithmic variations in the spreadspectrum wireless applications, they all share a common demand forincreased capacity to accommodate new users that continues to grow at anenormous rate.

Compounding this problem is the demand for new and more data-intensiveforms of wireless communication, such as data transfer with networks,e.g., Internet data transmission. In contrast, the resources availableto accommodate these demands, e.g., frequency bandwidth, aresubstantially limited. Consequently, a need arises for an apparatus anda method to effectively accommodate the increases in the quantity ofusers and the increase in the quantity of data transferred while using alimited frequency bandwidth.

Besides the variation between spread spectrum communicationapplications, substantial variations occur over time within a givenspread spectrum communication application. For example, within the codedivision multiple access (CDMA) cellular spread spectrum wirelessapplication, significant changes have occurred over time. These changestake the form of a proliferation of different versions and performancelevels, e.g., Telecommunication Industry Association (TIA) InterimStandard-95 (IS-95), IS54B, IS36, CDMA TIA IS2000 and TIA IS 2000A,European Telecommunication Standards Institute (ETSI) wideband CDMA(WCDMA), Global System for mobile communications (GSM), ARIB WCDMA,1Xtreme, GPRS, EDGE, etc. And the pace at which improvements and newstandards arise is increasing as more industry resources are focused onthe needs and opportunities in this wireless communication.Unfortunately, all these factors result in minimal uniformity around theworld at any one given point in time. For example, different countriesand different service providers frequently use systems that are uniquelydedicated to their specific version of a communication protocol.Consequently, a need arises for overcoming the limitations of protocolnon-uniformity and proliferation within each of the spread spectrumwireless communication applications.

The proliferation of communication protocols generates yet otherproblems. For example, the cost of changing communication protocols orupgrading versions or performance levels within a communication protocolcan be significant. That is, handset and base station designersfrequently improve the signal processing algorithms and processes toimprove service. Given the high quantity of base stations, as well asuser handsets, even a small unit cost for a change can multiply into avery large cost for the entire system. These costs are most pronouncedwhen a hardware change or when on-site field reprogramming is required.Furthermore, a software or hardware change for a new version orperformance level may hinder the efficiency of the existing deviceconfiguration due to incompatibility, etc. Consequently, a need arisesto overcome the limitations of cost and resource-intensive changes inversions or performance levels of a communication protocol.

Changes in performance level or versions of a communication protocol canalso affect the network services and coverage, and hence the survival ofa wireless service provider or a hardware manufacturer. For example,given the long lead time and the investment required for designing,manufacturing, and installing an infrastructure for a givencommunication protocol, a future but uncertain specification can be atremendous risk. This is especially so with an application specificintegrated circuit (ASIC) device whose configuration is definedprimarily by fixed hardware. However, market rewards may be significantfor the service provider or manufacture that is able to realize the newprotocol in the shortest possible time. Thus, a risk versus rewardtradeoff exists with implementing new communication protocols. Given thedegree of the risks and promise of rewards, a need arises to overcomethe limitations of the long lead-time and the investment required forimplementing a new specification.

With the increased sophistication of each new generation ofcommunication device, power consumption remains a significant issue.Among other things, power consumption affects: battery life for handhelddevices; cooling systems required for base stations; durability andreliability of semiconductor devices and integrated circuits; and otherperformance criteria. Conventional alternatives to hardwired ASICs havesignificant power consumption issues that offset their benefits.Consequently, a need arises to overcome the limitations in powerconsumption for a communication device.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus that caneffectively accommodate the increases in the quantity of users and thequantity of data transferred using the limited frequency bandwidth.Furthermore the present invention provides a solution that overcomes thelimitations of protocol non-uniformity and proliferation in the wirelesscommunications. The limitations of cost and burden associated withchanges in versions or performance levels of a communication protocolare also resolved by the present invention. In an effort to minimize therisks and maximize the rewards, the present invention substantiallyshortens the lead-time and the investment required for implementing anew specification. Finally, the present invention provides reasonablepower consumption for the communication device.

In particular, the present invention provides an apparatus and methodthat can flexibly and efficiently process data. One embodiment of thepresent invention is a processor with an architecture that includes afirst computing element, a second computing element, and areconfigurable interconnect. The first computing element is coupled tothe second computing element via the reconfigurable interconnect. Thefirst computing element performs a discrete operation, or portionthereof in an application, while the second computing element performsanother discrete operation, or portion thereof for the application. Thereconfigurable interconnect has an uncommitted architecture, therebyallowing it to be configured by an outside source to couple portions ofthe first reconfigurable interconnect with portions of the secondreconfigurable interconnect in any combination. The first computingelement, the second computing element, and the reconfigurableinterconnect operable to perform a class of functions suitable forprocessing the communication signal.

A second embodiment of the present invention provides a convenientmethod for operating the functional kernels having reconfigurablehardware to a configuration for implementing wireless communication. Ina first step of the process, a signal to be processed is received at areconfigurable modem platform having a heterogeneous multiprocessorarchitecture. Next, the signal is assigned to a data pump path in thereconfigurable modem platform. Then, design configuration informationfor the reconfigurable modem platform is received. Finally, the dataportion of the signal undergoes digital signal processing using thereconfigurable modem platform.

These and other objects and advantages of the present invention willbecome apparent to those of ordinary skill in the art after having readthe following detailed description of the preferred embodiments, whichare also illustrated in the various drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings included herewith are incorporated in and form a part ofthis specification. The drawings illustrate embodiments of the inventionand, together with the description, serve to explain the principles ofthe invention. It should be understood that the drawings referred to inthis description are not drawn to scale unless specifically noted assuch.

FIG. 1A is a block diagram of the interface functions accommodated bythe electronic spread spectrum communication device, in accordance withone embodiment of the present invention.

FIG. 1B is a block diagram of an electronic spread spectrumcommunication device having heterogeneous multiprocessor components, inaccordance with one embodiment of the present invention.

FIG. 1C is a block diagram of another configuration of an electronicspread spectrum communication device having heterogeneous multiprocessorcomponents, in accordance with one embodiment of the present invention.

FIG. 1D is a block diagram of an electronic system used to interface auser with a configurable multiprocessor device, in accordance with oneembodiment of the present invention.

FIG. 2A is a block diagram of a processor having multiple configurablehardware kernel planes used in the electronic spread spectrumcommunication device, in accordance with one embodiment of the presentinvention.

FIG. 2B is a block diagram of multiple possible architecture techniquesused in the algorithmic satellite kernel portion of the hardware kernel,in accordance with one embodiment of the present invention.

FIG. 2C is a block diagram of a configurable hardware kernel plane, inaccordance with one embodiment of the present invention.

FIG. 2D is a block diagram of a kernel portion of a hardware kernelplane, in accordance with one embodiment of the present invention.

FIG. 2E is a block diagram of a hardware kernel containing asubcomponent hardware kernel, in accordance with one embodiment of thepresent invention.

FIG. 2F is a block diagram of the inputs, outputs, and functionsaccommodated by the algorithmic satellite kernel in the electronicspread spectrum communication device, in accordance with one embodimentof the present invention.

FIG. 3A is a functional data flow diagram for configurablemultiprocessors in a modem application, in accordance with oneembodiment of the present invention.

FIG. 3B is an alternative functional data flow diagram for configurablemultiprocessors in a modem application, in accordance with oneembodiment of the present invention.

FIG. 3C is a block diagram of the codec functions accommodated by theelectronic spread spectrum communication device, in accordance with oneembodiment of the present invention.

FIG. 3D is a block diagram of the modem functions accommodated by theelectronic spread spectrum communication device, in accordance with oneembodiment of the present invention.

FIG. 4 is a block diagram of several user-defined modes of operationsperformed for modem signal processing functions in the electroniccommunication device, in accordance with one embodiment of the presentinvention.

FIG. 5 is a diagram of the separation and combining process of a singlethread into multiple concurrent threads to be accommodated on thecommunication device, in accordance with one embodiment of the presentinvention.

FIG. 6A is a flowchart of the process used to implement a designconfiguration onto a configurable spread spectrum electroniccommunication device, in accordance with one embodiment of the presentinvention.

FIG. 6B is a flowchart of the process used to operate a configurablespread spectrum electronic communication device, in accordance with oneembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the preferred embodiments of theinvention. Examples of the preferred embodiment are illustrated in theaccompanying drawings. While the invention will be described inconjunction with the preferred embodiments, it is understood that theyare not intended to limit the invention to these embodiments. Rather,the invention is intended to cover alternatives, modifications andequivalents, which may be included within the spirit and scope of theinvention, as defined by the appended claims. Additionally, in thefollowing detailed description of the present invention, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. However, it will be apparent toone of ordinary skill in the art that the present invention may bepracticed without these specific details. In other instances, well-knownmethods, procedures, components, and circuits have not been described indetail so as not to unnecessarily obscure aspects of the presentinvention.

The present invention can be implemented in a wide variety of digitalspread-spectrum wireless communication systems or techniques thatutilize code sequences. Code sequences are utilized in wirelesscommunications for many functions including, but not limited to:filtering, searching, modulation, and demodulation. The systems ortechniques which utilize code sequences include, but are not limited to,fixed wireless, unlicensed Federal Communications Commission (FCC)wireless systems, wireless local area network (W-LAN), cordlesstelephony, cellular telephony, personal base station, telemetry, andother digital data processing applications. The present invention can beapplied to both transmitters, e.g., a base station, and to receivers,e.g., a terminal, for fixed wireless, W-LAN, cellular telephony, andpersonal base station applications.

In particular, one fixed wireless application to which the presentinvention may be applied is a metropolitan multipoint distributionsystem (MMDS). Examples include wireless cable broadcast, or two-waywireless local loop (WLL) systems. Some examples of a W-LAN, that cancommunicates digitized audio and data packets, for which the presentinvention can be applied include Open Air, and the Institute ofElectrical and Electronics Engineers (IEEE) specification 802.11b. Inyet another application, a specific example of unlicensed FCCapplications to which the present invention may be applied includes theIndustrial, Scientific, and Medical band (ISM) devices, which caninclude cordless telephony products. Personal base stations can utilizeeither cordless or cellular telephony wireless communication standards.Lastly, the cellular telephony systems in which the present inventioncan be applied includes, but is not limited to, IS-95, IS2000, ARIB,3GPP-FDD, 3GPP-TDD, 3GPP2, 1Xtreme, or other user-defined protocols. Therange of code sequences utilized in the exemplary spread spectrumapplications disclosed herein, are useful to define the class offunctions for which the present configurable code generator unit isapplicable.

The detailed description of the present invention begins with adescription of an exemplary application, a spread-spectrum communicationdevice, in FIGS. 1A through 1D. In particular, spread spectrumcommunication device is described in FIG. 1A in terms of a functionalblock diagram, in FIGS. 1B and 1C in terms of hardware block diagrams,and in FIG. 1D as a block diagram of a virtual machine interface (VMI)that translates user-desired functions to device-level instructionsusing resident hardware and software. Next, FIGS. 2A through 2F describea configurable processor, and its configurable hardware kernelcomponents, in an increasingly detailed manner. A functional blockdiagram of a configurable hardware kernel is presented in FIG. 2F.Thereafter, the functional layout of hardware kernels in a configurablemodem processor for the exemplary spread-spectrum communication deviceis provided in FIGS. 3A through 3D for modem functions, and in FIG. 4for codec functions. FIG. 5 provides a diagram of function managementtechnique utilized by processors with configurable hardware kernels.Lastly, various processes associated with the communication device andthe hardware kernels are described in FIGS. 6A through 6C.

Communication Device

Referring now to FIG. 1A, a block diagram 10 of the interface functionsaccommodated by the electronic spread spectrum communication device areshown, in accordance with one embodiment of the present invention. Thesignal processing functions 16 shown have a configurable architecture inone embodiment that enables an electronic spread spectrum communicationdevice to operate using a wide variety of communication protocols,including CDMA, 3GPP, TDMA, as well as anticipated future protocols.Block diagram 10 provides a macro level description of the interfacefunctions. A more detailed description of the specific sub-functions andoperations, and the hardware that implements them are provided insubsequent figures herein.

The signal processing function block 16 of a communication device isresponsible for performing the data processing steps needed to convert areceived signal into meaningful data for an end user and to convert aninput from a user and convert it to a transmittable signal. Withinsignal processing function block 16, a wide variety of functions, subfunctions, and operations are performed to satiate the requirements ofthe specific communication protocol chosen for a communication device.For example signal-processing functions can include demodulation and/ordecoding for received in-phase and quadrature-phase (I/Q) samples 12,and include encoding and/or modulation for transmitted I/Q samples 14.Control data 20 provides the necessary control information, e.g., flags,handshakes, addressing, status, etc., to components such that signalprocessing functions 16 can be accomplished. Signal processing functionblock 16 also communicates with a traffic interface 18, to accommodatethe allocation of respective signals to each of the many differentwireless users operating within a given communication system. In thepresent embodiment, the traffic interface is a mobile telephoneswitching office (MTSO) for a cellular spread spectrum communicationapplication. However, another spread spectrum communication applicationmay not require a traffic interface, e.g., a cordless telephony spreadspectrum application. Processing function block 16 receives I/Q samples12 upon which known data processing protocols are implemented.Similarly, processing function block 16 transmits desired data as I/Qsamples 14 to another communication device (not shown). Configurationdata 11 inputs provides the necessary information to configure thehardware and software components used to implement signal-processingfunction block 16.

Referring now to FIG. 1B, a block diagram of an electronic spreadspectrum communication device having heterogeneous multiprocessorcomponents for processing data is shown, in accordance with oneembodiment of the present invention. Electronic spread spectrumcommunication device 100 includes subcomponents and configurations thatare illustrated and described in more detail in subsequent figures.Additionally, electronic spread spectrum communication device 100 alsoemploys methodology for design, configuration, and operation that willbe described in subsequent flowchart figures. While electronic spreadspectrum communication device 100 is a base transceiver station (BTS) inthe present embodiment, the present invention is well suited toelectronic spread spectrum communication device 100 being a mobilehandset or a test equipment platform.

Electronic spread spectrum communication device 100 includes aninterface conversion block 116, a modulator/demodulator (modem)processor 102 a, an optional configurable modem processor 102 b, memory106 and 118, a processor 112, a channel coder/decoder (codec) processor104, a base transceiver station (BTS) card controller 110 a, and an ATMUtopia/HDLC 108. Processor 112 can either be a digital signal processor(DSP) or general-purpose microprocessor (GP uP). External memory 106used for interleaving meets the following requirements for the presentembodiment: 1) 8 Mb SRAM; 2) 18 MHz Performance; 3) Minimum 512K×16configuration; 4) Byte write-enables. However the present invention iswell suited to alternative memory configurations, tailored for a givenspread spectrum application.

In the present embodiment, configurable modem processor 102 a, optionalconfigurable modem processor 102 b, and configurable channel codecprocessor 104 have a configurable heterogeneous multiprocessorarchitecture. Thus, configurable modem processor block 102 a andconfigurable codec processor 104 can be configured to operate a widerange of spread spectrum communication protocols, e.g., the exemplaryspread spectrum protocols described hereinabove. To do so, configurablemodem processor 102 a and configurable codec processor 104 are designedwith a sufficiently wide scope to accommodate the common and uniquerequirements of these varied spread spectrum communication protocols.Subsequently, the configurable modem processor 102 a and theconfigurable codec processor 104 are provided with the instructions anddata necessary to configure them, e.g., configuration input 121, to asingle desired spread spectrum protocol. Notably, the configurable modemprocessor 102 a and the configurable codec processor 104 cansubsequently be reconfigured to another spread spectrum protocol withinthe design scope. The hardware, software, and processes used toimplement this configuration are described in subsequent figures. Thespecific structure, components, functions, and processes utilized forthe present invention will be described in more detail if subsequenthardware, function, and flowchart diagrams. This architecture provideselectronic spread spectrum communication device 100 with a flexibleconfiguration that can accommodate a wide range of spread spectrumcommunication applications while simultaneously providing energyefficient operation. Thus the present invention overcomes the trade-offsassociated with prior art configurations, wherein a device was flexiblebut energy inefficient, or the device was energy inefficient butinflexible.

Configurable modem processor block 102 a includes at least one hardwarekernel plane in the present embodiment. The hardware kernel plane,described in subsequent figures, is a reconfigurable collection ofmultiple algorithmic-specific processors. The hardware kernel plane canimplement the sub functions of a functional kernel plane, described in asubsequent figure. In the present embodiment, Configurable modemprocessor block 102 a can be designed to accommodate multiple channelsof data, the specific number depending upon the needs of a specificapplication.

Channel codec functions are implemented by exemplary CODEC signalprocessor 104 of FIG. 1B, which is a reconfigurable multi-channeldigital channel encoder-decoder chip that performs convolution,iterative turbo decoding, rate-detection, and rate matching functionsfor a wide range of quantities of voice channels. Channel codecfunctions also implemented by channel codec signal processor 104 fortransmission encoding include convolution and turbo coder functions,puncturing, rate-matching, and interleaving on the transmit path, in thepresent embodiment.

By using a heterogeneous reconfigurable architecture together withapplication-specific kernels, as described hereinafter, a programmableand configurable signal-processing platform is realized. Theseconfigurations are completely under the control of the communicationsystems designer, and are described in detail in a subsequent flowchart.The architecture of the Channel Codec Signal Processor 104 of FIG. 1Bprovides a very high level of integration, while allowing thecommunication systems designer to employ proprietary techniques toimprove decoder performance in each of the stages described above. Thearchitecture of the Channel Codec Signal Processor 104 enables thesystem designer to program the chip at many levels, including control ofspecific datapaths to realize different algorithms. Details on thearchitecture and operation of codec processor are given in subsequentblock diagram figures and in flowchart figures.

Interface conversion block 116 is coupled to the antenna bus 129, whichis in turn coupled to an antenna, e.g., a BTS antenna 120, which caninclude multiple antennae in one embodiment. Interface conversion block116 is also coupled to configurable modem processor 102 a and tooptional configurable modem processor 102 b via bus 122, respectively.Bus 122 can be separate independent non-shared buses, or a single sharedbus. Interface conversion block 116 includes components (not shown) suchas a radio frequency (RF) transceiver and an analog to digital (A/D)converter coupled to each other in series, whose subcomponents andfunctions are known to those skilled in the art. Configurable modemprocessor 102 a and optional configurable modem processor 102 b arecoupled to a processor 112 and to memory 106, which is random accessmemory (RAM) in the present embodiment. Memory 106 is coupled to channelcodec processor 104, which in turn is coupled to ATM Utopia/HDLC 108 viabus 124. An internal data/control bus 126 is coupled to interfaceconversion block 116, memory 118, processor 112, BTS card controller 110a, and to ATM Utopia/HDLC 108 in order to pass data and controlinstructions between these components. ATM Utopia/HDLC 108 is aconventional asynchronous transfer mode (ATM) networking interface inthe present embodiment.

In one embodiment, uP 112 is a general-purpose microprocessor capable ofperforming the functions of BTS card controller 110 a. An external BTScell controller 114 is coupled to internal bus 126 and to a mobiletelephone switching office bus 128. ATM Utopia/HDLC 108 provides signalformatting, memory, and interface circuits for Operations andMaintenance (OAM) control. BTS Cell Controller 114 determines thepersonality (or radio configuration) of each channel element by loadingspecific configuration software into specific control registers in BTSChannel Card Controller 110 a, processor 112, configurable modemprocessor 102 a, and codec processor 104. Interface configurations andprotocols are described in FIG. 1C.

By using processor 112 in communication device 100, the presentinvention provides the ability to use existing digital signal processingresources, while upgrading other processing resources to more flexibleand efficient hardware, e.g., configurable modem processor 102 a. Inparticular, functions that were performed on general-purpose processorsare performed by the present invention on operation-specific, oralgorithmic-specific, processors that are interconnected to realize amodem or codec function. Furthermore, the operation-specific processorspossess the appropriate amount of configurabiltiy for protocolvariations, thereby providing robustness for future developments. Byproviding configurabiltiy, the present invention provides acommunication device with the flexibility to operate under a wide rangeof communication protocols, such as IS-95, CDMA-2000, 3GPP, andtime-division multiple access (TDMA), to name a few.

Electronic spread spectrum communication device 100 is responsible forprocessing voice, data, and control signals in a transmission andreception mode. In pursuit of these functions, BTS card controller 110 aprovides a number of interfaces. In the present embodiment, BTS cardcontroller 110 a provides: 1) antenna receive (RX) Bus 129 to receivethe uplink digitized signal samples; 2) BTS Cell Controller for sendingand receiving control information associated with call setup, teardown,and handoff; and 3) Operations and Maintenance (OAM) Monitor forperformance analysis, reconfiguration over the network based on systemplanning, and troubleshooting.

Alternative components and configurations to communication device 100are compatible with the present invention. For example, bus 126 providesan exemplary coupling configuration of components in electronic spreadspectrum communication device 100. It is appreciated by those skilled inthe art that bus 126 can include subcomponents of specificcontrol/status/data lines for communication between appropriate devices.It is further appreciated by those skilled in the art that bus 126 canbe a parallel configuration or serial configuration with multiplexing.Furthermore, bus 126 can have interconnects and translators, asappropriate for a given application. These alternatives are alsosuitable for buses 129, 128, 127, 130, 122, and 122 a, and other busesthat can be used to couple components in communication devices 100 and101 of FIGS. 1B and 1C, respectively.

Additionally, communication device 100 is well suited to alternativecomponents and coupling configurations of memory 106. For example, whilememory 106 is located between configurable modem processor 102 a, andchannel codec processor 104 in the present embodiment, the presentinvention is well suited to coupling configurable modem processor 102 adirectly to channel codec processor 104 and to locating memory 106directly adjacent to channel codec processor 104. While memory 106 and118 are specified as RAM in the present embodiment, the presentinvention is well suited to a wide range of memory configurations, suchas ROM, registers, flash memory, etc. While antenna 120 is shown as aBTS antenna having multiple individual antennae arranged in sectors, thepresent invention is well suited to antenna 120 be a single or dualantennae for a mobile handset or a test platform application.

While the present embodiment provides both a configurable modemprocessor 102 a and a configurable codec processor 104 in communicationdevice 100, the present invention is well suited to an alternativeconfiguration that uses a configurable modem processor 102 a with aconventional codec processor (e.g., a digital signal processor), and tousing a configurable codec processor 104 with a conventionalconfigurable modem processor. Lastly, while the present inventionprovides a single modem processor, with a single optional configurablemodem processor 102 b, the present invention is modular, and thus iswell suited to using a wide range of processor types and quantities, asappropriate for a given spread spectrum application. Communicationdevice can also include a configuration that accommodates multiplecommunication standards. For example, the present invention can beapplied to communication protocols such as orthogonal frequency divisionmultiplexing (OFDM). More detail is provided in a commonly assigned andrelated application, which is incorporated herein by reference andentitled “METHOD AND APPARATUS TO SUPPORT MULTI STANDARD, MULTI SERVICEBASE-STATIONS FOR WIRELESS VOICE AND DATA NETWORKS,” Attorney Docket No.9824-0035-999, U.S. patent application Ser. No. ______, filed on Dec.28, 2000.

Referring now to FIG. 1C, a block diagram of another configuration of anelectronic spread spectrum communication device having heterogeneousmultiprocessor components is shown, in accordance with one embodiment ofthe present invention. Second configuration 101 of electronic spreadspectrum communication device has many components and configurationsthat are similar to those shown in FIG. 1B. Thus, components andcoupling configurations different from FIG. 1C are primarily discussedhereinafter.

Communication device 101 includes a BTS card controller 110 b that canbe a state machine or an optional microprocessor. Bus 127 couples memory118 and BTS card controller 110 b to channel codec processor 104 andconfigurable modem processor 102 a. This provides a more direct dataroute between memory 118 and configurable modem processor 102 a andchannel codec processor 104. Additionally, memory 106 is locatedadjacent to channel codec processor 104, and coupled to BTS cardcontroller 110 b, and provides improved communication and processing tochannel codec processor 104. It also provides improved communication andprocessing between channel codec processor 104 and modem processor 102a. While only one configurable modem processor 102 a is shown in FIG.1C, communication device 101 is well suited to using more than oneconfigurable modem processor, as appropriate by a given application.Communication device 101 does not have a separate conventional DSP chiplike communication device 100. Rather, communication device 101 utilizeseither an external general purpose microprocessor 103 or utilizescomputing elements within configurable modem processor 102 a and channelcodec processor 104 to perform functions traditionally provided by aconventional DSP chip. The alternative configurations and componentsdiscussed for communication device 100 are likewise applicable tocommunication device 101.

Interface configurations and protocol are utilized between componentswithin communication device 100 and 101 as well as between componentswithin and outside of communication device 100 and 101. For example, abus interface 130 a and 131 of communication device 100 and 101,respectively, is provided for streaming the received, coded symbols fromthe modem Signal Processor 102 a and/or 102 b to the Channel CodecSignal Processor 104. Similarly, bus interface 131 is provided forstreaming the encoded transmit data from Channel Codec Signal Processor104 into the modem signal processor 102 a-102 b (assumed to beinterleaved on Channel Codec Signal Processor). Busses 130 a and 130 bof FIG. 1B and bus 131 of FIG. 1C combine a hand-shaking mechanism witha well-defined data stream in order to provide necessary flexibility inprogramming. Interface conversion/sector combining block 116 provides ahigh-speed parallel interface for communicating digitized I/Q samplesbetween the Modem Signal processors 102 a and 102 b, and antenna 120,for an uplink or downlink embodiment. Two parallel ports 122 (one forI/Q uplink, one for I/Q downlink) are provided for multiplexed interfaceto multiple antennae, e.g. in antenna array 120 for a base station inthe present embodiment. Memory interface 132 is provided for interfacingto an external SRAM 106 for support of necessary deinterleaving requiredfor high data rate support. The interface assumes that a single memoryresource may be shared across multiple modem signal processorimplementations 102 a (up to three modem signal processor's per memory),so that semaphores are required for coordinating, via input 134 from BTScard controller 110 b, the necessary memory writes and establishing asingle modem signal processor as the Burst Controller for frame burstsout of the Deinterleaver memory. A well-defined memory map within memory106 is used to avoid fragmentation across external memory 106.

The functions and interfaces shown in FIG. 1A are implemented, in oneembodiment, using hardware shown in FIGS. 1B-1C, and using subcomponentsdescribed in subsequent figures. For example, received I/Q samples 12are provided to signal processing function block 16, via bus 129 of FIG.1B in the present embodiment. Similarly, the signal processing functionsrequired for an application are performed by communication device 100 ofFIG. 1B or device 101 of FIG. 1C. Thus, for example, transmitted I/Qsamples 14 and received I/Q samples can be communicated via bus 129to/from antenna 120. Traffic interface 18 is accommodated via bus 128,and control data 20 is accommodated via bus 126, in one embodiment.While the functions described are attributed to a base transceiverstation (BTS), the present invention is well suited to implementing thefunctions and appropriate interfaces on a mobile handset. For example, amobile handset would not have an MTSO traffic interface, but wouldinclude the balance of the interfaces and functionality of FIG. 1A.While the present embodiment only describes configurable processors fortwo function types, e.g., modem and codec functions, and applies them toa wireless communication application, the present invention is wellsuited to accommodating other functions for other applications in asimilar manner.

Referring now to FIG. 1D, a functional block diagram 150 of a systemused to interface a host-processor containing a users program ofconfigurations with a configurable multiprocessor device is shown, inaccordance with one embodiment of the present invention. Theconfigurable components, e.g., hardware kernels and interconnect of FIG.2C, for communication device 100 can be programmed by user-definedconfigurations. The user-defined configurations can be generated by auser from a host microprocessor, e.g., a workstation, which implements aprogramming interface (API).

Processor hardware (HW) model 160 is a block diagram representing theinteraction of hardware, e.g., a processor 112, with software and datasuch as library functions, instructions, and configuration data, that isstored in memory. Processor software model can be programmed with avirtual machine interface (VMI) in one embodiment. Specifically,processor 112 can be modeled as a software model consisting of user'sC-language code (or software) 164 and I/O device drivers 166. The userprovided C-language software 164 in order to configure configurableprocesses 170 of the configurable modem 102 a and 102 b, and of theconfigurable coded 104. C-language software 164 includes residentuser-implemented C language block of instructions and functions thatinterface with input/output (I/O) driver block 166. C language block 164is coupled to receive C-based application programming interface (API)programming guide data 171, which includes a library of functions forprogramming configuration inputs 121 a through 121 e to appropriateconfiguration mappings. Similarly, processor software model 162 iscoupled to receive input 172 of API functions mapped to instruction set171 and 172. Each API function of input 172 includes a set ofinstructions which will: 1) map the API function to a specific hardwarekernel and reconfigurable interconnect (e.g. DRL) process; 2) describethe DRL process as a set of data structures/configuration signals thatare passed via hardware interfaces 168 by host processor 112. APIProgramming Guide 171 serves as a reference to access the modes offlexibility in the modem signal processor.

Hardware interfaces block 168 is coupled to processor 112 to receivedevice driver information appropriate for the configuration input 121 athrough 121 e. In turn, hardware interfaces block 168 is coupled toprovide configuration instructions and data, e.g., driver information,to dynamically reconfigurable logic (DRL) block 170. DRL processes block170 represents the ultimate desired processes (or functions) to beimplemented by the configurable communication device, e.g., device 1100of FIG. 1B. DRL processes block can communicate configuration mappingdata 174 to appropriate configurable components, described in subsequentFIGS. 2A through 2G, of configurable communication device 100, which canstore and transmit instruction sets of mapped API functions.

User-implemented C-language block 164 provides a user with the abilityto control the configuration of a hardware kernel, described insubsequent FIGS. 2C through 2E. In particular, the programmer/user canprovide the following inputs to define the configuration of aconfigurable hardware kernel: 1) inputs, as shown by input 121 a; 2)outputs, as shown by input 121 b; 3) operation(s) to be performed, asshown by input 121 c; 4) parameters, as shown by input 121 d; 5) a typeof arithmetic in a processing unit (e.g., dataflow process); and 6) typeof state machines controlling the dataflow process (e.g., controlflowprocess) as shown by input 121 e. In addition, user-implementedC-language block 164 provides a user with the ability to control thereconfigurable interconnect that link multiple hardware kernels within akernel plane. Thus, input 121 e includes user-specified interconnectconfigurations (i.e. interconnect reconfigurability). The presentinvention is well suited to using less inputs and control or providingadditional inputs or control for a user to configure a configurabledevice.

Interconnect configuration input 121 e specifies the configuration ofreconfigurable interconnect such that a cluster(s) of kernels may bebuilt. This level of control with individual kernels and theinterconnect offers substantially greater flexibility than that ofhardwired or parameterized application specific integrated circuit(ASIC) solutions. By using kernels that are focused to the specifictypes of data processing found in terrestrial and wireless communicationapplications, the computational efficiency, in millions of operationsper milliwatt (MOPS/mW) of this architecture approaches that of an ASIC.

Functional block diagram 150 shows the hierarchy with which a user mayinterface DRL processes block 170. That is, the hierarchy includes: a) afirst level with a C-based interface 164 with a user; b) a second levelwith an I/O device driver 166 interface between the C-language and thehardware interfaces; c) a third level with hardware interface block 168that interfaces between the DRL process 170 and the processor HW model160. Thus, the present embodiment utilizes a hierarchical ApplicationProgramming Interface (API) that supports several levels of user controlfor programming a Channel Codec Signal Processor, e.g., codec processor104, or a configurable modem processor 102 a, as shown in FIG. 1B.Dashed box 176 includes the API functions mapped to instruction set data172, and the configuration mappings data 174. Dashed block 176 indicatesthe control software, which includes a subset of functions defined bythe API. The control software block 176 enables the function of theconfigurable communication device, e.g., device 100 of FIG. 1B.

C-based API programming guide 171 utilizes a mechanism referred to asExtensible Data Types (EDT), described in more detail in a subsequentflowchart. The use of EDT effectively embeds a mechanism in the API thatallows additional functionality to be transparently added, the API isable to add new hardware services without the need to modify existingsoftware. This mechanism must also provide this abstraction withoutsignificant performance overhead. By the use of pointer access to datatypes and inline functions, this effect is minimized. By abstracting thehardware from the software, the API allows the hardware and softwaredevelopment processes to be decoupled from one another. Thissignificantly reduces development time, as each hardware upgrade ormodification does not require changes to the software. Modes ofconfigurations are specified in the API programmer's guide 171 forhardware kernel blocks. API programmer's guide 171 describes the alloweddataflow configurations (i.e. hierarchical interconnect configurations)of the machine. Appendix A provides an exemplary sequencing of the modemand codec functions described therein to realize a variety oftransceiver signal paths by configuring the kernels and interconnectaccording to the types of operations and dataflow desired.

Through the use of extensible data types, a hardware configuration canbe constructed to support various WCDMA standards. Furthermore, thetypes can be configured to support various performance requirements forthe system as a whole, for a set of mobiles, or for a particular mobile.Hardware configurations are realized through an API that allows aprogrammer to manipulate the relationships between various extensibledata types. The resources available in an extensible data type directlymap to available hardware resources. A programmer using the API canconfigure the hardware resources from a conceptual viewpoint.

The programmer's model and API (or VMI) of FIG. 1D defines and providesa mechanism for a user to systematically and efficiently developsoftware that controls the function and operation of the configurablecommunication device, e.g., 100 of FIG. 1B. The API allows theprogrammer to manage the hardware resources without the need to writecomplex low-level hardware-target-dependent code. This provides manyadvantages including ease of adoption and integration of theconfigurable communication device. Subsequent flowcharts provide moredetailed description of the process for developing the software tocontrol the configurable communication device.

By providing a high level API, a user can design their software in atop-down fashion. This enables top-level system problems to be rapidlyidentified and Corrected before the low-level code is written.Additionally, this approach saves a significant amount of developmenttime as is removes the need to rework low-level software to match highlevel changes.

The programmers model and API of FIG. 1D also provides efficient use ofhardware parallelism. Thus, the present invention provides a method andarchitecture that overcomes the challenging task of scheduling the manyhardware resources in the complete system. This requires an efficientmechanism for communication between the hardware resources, both withina configurable processor, e.g., within configurable modem processor 102a of FIG. 1B, and between the configurable processors (e.g., betweenconfigurable modem processor 102 a/codec processor 104 and thecontrolling processors, e.g., processor 112, BTS card controller 110 aor 110 b, and BTS cell controller 114 as shown in FIGS. 1B and 1C). Thehardware utilization, scheduling, and maintenance are under the controlof the API. By embedding these mechanisms in the API, a process can bedesigned in isolation, with the synchronization issues handled at onlyone level within the software hierarchy. This produces a system that isconsiderably quicker to build and more efficient in the use of hardwarethan one that uses many synchronization techniques within the design.RAVI: WRONG: Additional description on the process for providing C-basedAPI programming guide 171 and API functions mapped to instruction set172 is provided in co-pending patent application entitled “A METHOD FORDESIGINING A CONFIGURATION FOR A CONFIGURABLE SPREAD SPECTURMCOMMUNICATION DEVICE,” Attorney Docket No. 9824-083-999, U.S. patentapplication Ser. No. ______, filed on Jan. 29, 2001. This relatedapplication is commonly assigned, and is hereby incorporated byreference.

The present embodiment of FIG. 1D can include additional features forindividual versions of the software. Examples of this would be an inputdata formatter to deal with the incoming data format on a particulartest rig, or the creation of a software version that performs functionprofiling or debugging on a particular section of the software, withouthaving the attendant performance degradation on other blocks. Both ofthese alternatives are dealt with efficiently by the use of extensibledata types, which allow a user to rapidly modify the functionality ofthe software by modifying the data types and recompiling.

Appendix B hereinafter provides several exemplary computer programs thatcan be implemented in functional block diagram 150 in order to providean interface between a user and a configurable processor. In particular,Appendix B provides the specific application of a wireless basetransceiver station for an exemplary CDMA spread spectrum application.However, the present invention is well suited to a wide range of spreadspectrum communication applications. It is appreciated that one skilledin the art can interpret the computer language specific syntax providedin these examples.

Hardware Kernels

Referring now to FIG. 2A, a block diagram of a configurable modemprocessor 102 a having multiple configurable hardware kernel planes usedin an electronic spread spectrum communication device is shown, inaccordance with one embodiment of the present invention. Codec processor104 of FIG. 1B can have a configuration similar to that of FIG. 2A inone embodiment. FIG. 2A illustrates how the multiple hardware kernelplanes interconnect and shows what device controls and coordinates them.Processor 102 a can be configured to operate as a configurable modemprocessor 102 a and 102 b or as a configurable codec processor 104, asshown in FIGS. 1B and 1C, in the present embodiment.

In the present embodiment, two hardware kernel planes, e.g., plane [1]201 a and plane [i] and 201 i, are coupled to an allocator 219 via areconfiguration bus, e.g., 206 a and 206 i, respectively. Each hardwarekernel plane is assigned to a given channel in a communication system inthe present embodiment. In turn, allocator 219 is coupled to ageneral-purpose (GP) microprocessor or signal processor 112. To reduceoverhead in terms of instruction fetch and global control, thearchitecture utilizes distributed control and configuration. Thecommunication mechanism between each kernel is dataflow driven.Allocator 219 performs controller operations for each of the kernelplanes 201 a and 201 i, such that they can operate independent of eachother, e.g., in parallel.

To perform these functions, allocator 219 includes memory and statemachine components. In one embodiment, allocator 219 is configurablesuch that it can manage the desired type of functions implemented in thehardware kernel planes 201 a through 201 i. For example, allocator 219can be configured such that hardware kernel planes 201 a through 201 iperform modem functions, or alternatively codec functions. While thepresent embodiment shows only two hardware kernel planes 201 a and 201i, the present invention is well suited to using any quantity ofhardware kernel planes in processor 102 a. Hardware kernel planes 201 aand 201 i include a configurable heterogeneous multiprocessorarchitecture that will be described in more detail hereinafter. Data bus122 provides data to and from configurable modem processor 102 a, asdoes data line 130 a, as shown in FIG. 1B.

Processor 112 performs higher-level management operations for theallocator. In this manner, multiple instances of processor 102 a can beaccommodated in a communication device, and can operate in varyingdegrees of parallel processing. In the present embodiment, processor 112is a system processor of the parent communication device 100 FIG. 1B.However, configurable processor 102 a can have a dedicated localmicroprocessor in lieu of system processor 112.

Referring now to FIG. 2B, a block diagram 200 b of multiple possiblearchitecture formats used in a hardware kernel portion of a spreadspectrum communication device is shown, in accordance with oneembodiment of the present invention. By using multiple levels ofgranularity in its components, the communication device possesses a widebreadth of efficient programmability. And efficient programmabilitytranslates into accommodating of multiple non-uniform specifications bya communication device. With each level of granularity having its ownpreferred target for a given application. A systematic and hierarchicalmethod to exploit the flexibility of incorporating these differentarchitectures into hardware is described in a subsequent flowchartfigure.

FIG. 2B shows the four main levels of programmable or reconfigurablegranularity used in a hardware kernel in the present embodiment. Thedifference in the various computational models shown in FIG. 2B lies inthe granularity of the composing modules, the distribution of theprogram storage, and the interconnect structure. In one embodiment, thecomputing elements in a hardware kernel can exploit any combination ofthe four types of reconfigurability, in an architecture referred to asDynamically Reconfigurable Logic (DRL), described in more detailhereinafter. However, the present invention is well suited toincorporating other types of computational models that have differentlevels of granularity or different applications of granularity.

A first architecture format is referred to as reconfigurable logic 211.Reconfigurable logic 211 uses multiple processing islands, also referredto as a configurable logic block (CLB), e.g., 210 a coupled by aninterconnect 214 with reconfigurability, via bus lines, e.g., 212 a, 212b, 213 a, and 213 b. The reconfigurable logic type of engine reliesalmost exclusively on bit-level mesh networks in the present embodiment.In the present embodiment, interconnect 214 provides all possiblecoupling arrangements between the bus of data liens 212 a and 212 b. Inthis manner, independent blocks 210 a-210 d can communicate with oneanother in any desired manner. That is, they are not restricted tocommunicating with less than all existing kernels due to limitedhardware wiring. In another embodiment, interconnect 214 can provideonly a limited amount of interconnectabiltiy, based upon perceived needsand capabilities of each kernel for a given application. Reconfigurablelogic 211 uses bit-level operations such as encoding. By itself,reconfigurable logic provides significant benefits of flexibility.However, the flexibility comes at a trade-off of inefficiency in chiparea and in power consumption. In one embodiment processing islands haveunrestricted reconfigurability of its component logic devices.

A second architecture format is referred to as reconfigurable datapath221. The interconnect network of the reconfigurable datapath exploitsthe bit-sliced structure and predominantly one-dimensional flow of databy using an asymmetric network-reconfigurable buses in one direction andbit-level mesh in the other direction. That is, reconfigurable datapath221 uses dedicated datapaths to transmit data between electroniccomponents, such as mux 220 and adder 226. For example, multiplex (Mux)block 220 can multiplex data from multiple data lines onto a single dataline, thus changing the data path. Additionally, data may be directedalong one of multiple paths to an appropriate storage register, e.g.,register 0 (Reg0) or register 1 (Reg1). From an appropriate storageregister, data may be directed along a path to a given function block,e.g., adder 226 or buffer 228. Reconfigurable datapath 221 canefficiently move data, but it lacks flexibility that is not built intothe original architecture. Thus, for example, the data path is limitedto the data lines built between components, e.g., 220 through 228.

A third architecture format is referred to as reconfigurable dataflow231. With reconfigurable dataflow, control exists over the type ofarithmetic used in a processing unit (i.e. dataflow process). Thereconfigurable dataflow architecture uses a program and data bus thatfeeds data and control instructions to a computation unit. Inparticular, block 232 a and 232 b generate addresses to get data frommemory, e.g. 234 a and 234 b, to be sent to a multiply-accumulate (MAC)block 236 for processing.

A fourth architecture format is referred to as reconfigurable logic 241.Reconfigurable logic 241 refers to a real-time operating system (RTOS)where the outside source controls the type of state machines thatcontrol the dataflow process (i.e. controlflow process). Withreconfigurable logic 241, the stored-instruction engines rely on sharedbuses for the transfer of data and instructions. Block 240 is the datamemory storage of data to be processed, while block 242 is the programmemory for storing program instructions used to run on instructiondecoder and controller 246. Block 394 is the datapath block, whichcontains the arithmetic operations for processing the data. Memory block390 b is a second bank of data memory for interfacing data with datapath block 394.

By combining these four types of architecture, as described hereinafter,in a manner that matches the programming, function, or temporalgranularity needed for a given algorithm, function, application, and/orclasses thereof, the present invention provides a hybrid architectureand system. This hybrid architecture and system provides substantialimprovements in performance over previously irreconcilable tradeoffs ofspeed, flexibility, and efficiency.

Referring now to FIG. 2C, a block diagram of a hardware kernel planeused in the electronic spread spectrum communication device is shown, inaccordance with one embodiment of the present invention. Hardware kernelplane 201 a provides the capability of reconfigurability for a range ofprotocols in an application, or within a range of applications, with anefficiency that challenges conventional circuits. Additionally, hardwarekernel plane 201 a is modular, and thus may be designed to operate ingroups.

Kernel plane 201 a includes multiple hardware kernels K1 261 a throughK6 266 a that are coupled to a reconfigurable interconnect 204 a. Datais passed between kernels K1 261 a through K6 266 a via reconfigurableinterconnect 204 a. Control information, such as handshake protocolsignals, can also be routed through reconfigurable interconnect 204 a.Hardware kernel, e.g., K1 261 a, is described in detail in a followingfigure. Interconnect architecture supports sufficient concurrency withineach of the hardware kernels K1 261 a through K6 266 a. In the presentembodiment, reconfigurable interconnect 204 a utilizes a hierarchicalstructure that can support the required interconnect patterns (asdescribed by the dataflow in following flowchart figures), as well asprovide good performance and energy efficiency for every configuration.While the present embodiment uses six hardware kernels, the presentinvention is well suited to using any quantity of kernels in kernelplane 201 a.

In the present embodiment, hardware kernels K1 261 a through K6 266 akernels are specific to the types of data processing found in wirelesscommunication applications, such as CDMA. However, at the same time,hardware kernels K1 261 a through K6 266 a are heterogeneous withrespect to one or more of each other, in terms of programmability,algorithmic-capability, performance-level, and/or math-logic. However,two or more kernels within kernel plane 201 a can be homogeneous withrespect to each in another embodiment. The specific composition andrelationship between hardware kernels depends upon the specificapplication. Examples of these levels of programmability are provided ina subsequent figure. One or more of hardware kernels K1 261 a through K6266 a are also autonomous with respect to each other, thus allowingparallel processing of data, on a kernel-by-kernel basis, or on akernel-group by kernel-group basis. Because of this autonomy, and localcontrol, the individual hardware kernels as well as the hardware kernelplane is data-rate scalable to a range of system clock rates.

Kernels K1 261 a, K4 264 a, and K5 265 a are grouped together inhardware kernel group A 268 a. Similarly, hardware kernel K3 263 a isidentified as a sole kernel within hardware kernel group B 268 b. Thesetwo exemplary kernel groupings provide a class of functions for thepresent host communication device which applies them to a wirelesscommunication protocol application, as will be described in a subsequentflowchart figure.

Hardware kernels, e.g., kernel K1 261 a are coupled to a configuration(or reconfiguration) bus 206 a, e.g., via line 274. Configuration,status, and control information are passed to kernels K1 261 a throughK6 266 a via reconfiguration bus 206 a, in the present embodiment.However, the present invention is well suited to passing different typesof data and information using a wide variety of data lines and data busconfigurations.

Reconfigurable interconnect 204 a has an architecture that is primarilya reconfigurable logic 211, as described in FIG. 2B. In this embodiment,reconfigurable interconnect 204 a provides connectivity betweeninput/output lines of multiple kernels, or between input/output lines ofa kernel with components outside of kernel plane, e.g., allocator 219,processor 112 shown in FIG. 2A, or other data buses (not shown). Data ispassed between kernel plane 201 a and the host communication device viaan input/output line, e.g., line 122, that is coupled to reconfigurableinterconnect 204 a.

In one embodiment, reconfigurable interconnect 204 a has only a limitedamount of reconfigurability based upon the specific needs identified fora class of protocols in a given application, or for a class ofapplications. That is, based on an application, algorithm, function,operation, or class thereof, not all kernels will be required to havefull interconnectabiltiy with all other kernels. Consequently, thepresent embodiment provides limited reconfigurability of interconnect204 a between kernels depending upon the needs of the application,function, algorithm, etc. for which a kernel is designed. The limitationon interconnectabiltiy provides the benefit of reconfigurability whereit is needed, and restricts interconnectabiltiy where it is not needed.Thus, the inefficiently of a totally reconfigurable interconnect istempered by identifying strategic scenarios where reconfigurability isappropriate. The strategic scenarios involve the class of functions tobe performed, the design of individual kernels K1 261 a through K6 266 ato accommodate the class of functions, and the level of programmabilityprovided for outside control. The common ground between the class offunctions, operations, or algorithms is a case-by-case basis requiringanalysis of variables such as mathematical basis, signal processingoperations, algorithmic patterns, and silicon implementation.

Data is provided and received from kernel plane via data bus 122 or dataline 130 a. In the present embodiment, an input data line portion ofdata bus 122 is coupled to one side of reconfigurable interconnect 204 ato provide data input to kernel plane 201 a. Similarly, an output dataline portion of data bus 122 is coupled to the other side ofreconfigurable interconnect 204 a to receive data from kernel plane 201a. Data that is provided to reconfigurable interconnect 204 a is thenrouted to appropriate kernels K1 261 a through K6 266 a perconfiguration information provided to communication device.Alternatively, an input line portion of data bus 122 can be directlycoupled to one or more of kernels K1 261 a through K6 266 a, e.g., ifthis functionality of a particular kernel is consistent across a rangeof spread spectrum applications. For example, if a kernel plane for amodem operation always initially performs an interpolation filteroperation on input data regardless of the applications within a class ofspread spectrum communications, then input data line may be routeddirectly to the kernel responsible for this function. The same couplingarrangement can be provided for data line 130 a with respect toreconfigurable interconnect 204 a and kernels K1 261 a through K6 266 a.While the present embodiment provides for less than fullinterconnectabiltiy, the present invention is well suited to providingthe full interconnectabiltiy between all kernels.

The modem signal processor is one instance of the heterogeneousreconfigurable architecture, which can be configured to provide acomplete signal path for multichannel operation of a CDMA base-station.The hardware kernel processors were designed with a strong focus onapplying the flexibility vs. computational efficiency trade-off to thespecific needs of an application. As such, a rank ordering of thedominant computation-intensive kernels found in the algorithms isidentified. For example, in a typical WCDMA application, the dominantcomputations are centered around five major signal processing functions:chip matched filtering, code-epoch search, chipdemodulation/despreading, channel decoding, and inter-path (IPI)equalization (optional). While the present invention provides anenumerated list of computational categories for a hardware kernel, thepresent invention is well suited to using specific quantities and typesof categories as is appropriate for a given application.

Bus 206 a of FIG. 2C is selectively reconfigurable to provide only theneeded amount of interconnectivity to a kernel based upon theapplication, function, and/or algorithm, for which a kernel is designed.For example, in one embodiment, kernel K3 263 a does not require astatus flag because the operation it performs requires no feedback andis run to completion. Thus, reconfiguration bus 206 a provides no buscapability to kernel K3. In another embodiment, however,interconnectivity to provide communication of status information betweena hardware kernel with another hardware kernel or allocator can beprovided.

Referring now to FIG. 2D, a block diagram of a kernel portion of ahardware kernel plane is shown, in accordance with one embodiment of thepresent invention. Kernel K1 261 a provides one embodiment of manypossible embodiments, which any of multiple hardware kernels in a kernelplane may use.

Kernel K1 261 a includes a configuration information block 272 and asatellite kernel block 270, coupled to each other by interconnect 276.Satellite kernel 270 has an input/output data line 278, which is a busin the present embodiment, that provides communication withreconfigurable interconnect 204 a of FIG. 2C. Similarly, configurationinformation block 272 is coupled with reconfiguration bus 206 a of FIG.2C, via configuration line 274. In one embodiment, configuration line274 is a bus into configuration information block 272, or can be asingle line with multiplexed data. The amount of data the bus or singleline can handle can vary widely, depending upon the needs of an existingor projected application. Satellite kernel 270 is an electronic device,which is algorithmic specific in the present embodiment.

Configuration information block 272 is random access memory (RAM) in thepresent embodiment. However, the present invention is well suited tousing any medium for configuration information block 272 that canpreserve and communicate a state condition for electronic devices. Forexample, configuration information block 272 can be registers, flashmemory, or a state machine, e.g., using reconfigurable logic, thatprovides bit stream of states to satellite kernel block 270. By havingconfiguration information block 272 as a local dedicated source, thatcan also be controlled local to satellite kernel 270. This arrangementprovides a very quick and efficient changing of configuration data foralgorithmic satellite kernel 270. Consequently, time-sharing of ahardware kernel is feasible and practical in the present embodiment.

In the present embodiment, hardware kernels e.g., K1 261 a through K6266 a of FIG. 2C, have been designed to fit into one of multiplecategories of data processing applicable to wireless communication. Thecategory of data processing refers to the operational speed of thehardware kernel, which includes an energy-flexibility tradeoff. Thespecific category for which a hardware kernel is designed is determinedfrom the number and type of operations per sample of data processed inthe hardware kernels. The present embodiment utilizes five domains ofsignal processing categories for a wireless communication system. Theyinclude: 1) Sub-chip-rate (M times chip-rate=Mfc); 2) Chip-rate(chip-rate=fc); 3) Sub-symbol rate (fc/L, with multiple chips perprocessing period, which is less than one symbol interval); 4)Symbol-rate (fc/N=fs=symbol rate); and 5) Multi-symbol rate (fs*K, withmultiple symbols per processing period, which spans more than onesymbol).

The kernel processors cover the multi-standard CDMA signal processingrequirements, and can be categorized corresponding to classes of MOPS.In the present embodiment, signal processing for a wirelesscommunication application includes the following classes of MOPS: 1)Code Demodulation/Dechannelization; 2) Code Generation; 3) ParameterEstimation; 4) Sequence Alignment and Combining; 5) Equalization(optional); and 6) Front-end Processing.

Satellite kernel 270 includes a controller 271 and a configurablecomputation kernel (or algorithmic-specific computing element) 273 a,coupled to each other via a clock line 279 and a control line 284.Configurable computation kernel 273 a is also referred to as a computingelement or a processing engine.

Controller 271 includes a state machine with memory, in the presentembodiment, that is capable of controlling configurable computingelement 273 a. In another embodiment, controller 271 includes onlymemory that is capable of preserving state conditions of at least oneconfiguration of configurable computing kernel 273 a. To achievedistributed control, kernel K1 261 a is equipped with an interface thatenables it to exchange data streams with other kernels efficiently,without the help of a global controller. Hardware kernel K1 261 a uses adistributed control and configuration via local controller 271, whicheffectively reduces overhead in terms of instruction fetch and globalcontrol. Kernel K1 261 a also includes an interface, e.g., inconfigurable computation kernel 273 a, that enables it to exchange datastreams, e.g., data line 278, with other kernels efficiently, withoutthe help of a global controller. The communication mechanism betweeneach kernel is dataflow driven in the present embodiment. Localcontroller 271 can provide local control signals for initiation, reset,and interrupt for configurable computation kernel 273 a, as well asscaled clock rates.

In the present embodiment, configurable computation kernel 273 a isdesigned specifically to perform a given algorithm, function, operation,or class thereof. Therefore, satellite kernel 270 has flexibility, e.g.,reconfigurability, within the class of functions, operations, oralgorithms to which it has been designed. By virtue of the fact thatconfigurable computation kernel 273 a is designed for a relativelynarrow application in the present embodiment, it is consequently veryenergy efficient. Thus, it meets the needs of a wide range ofcommunication protocols within a spread spectrum category, while beingvery efficient. Additionally, because satellite kernel 270 has its ownlocal controller 271, it operates autonomously with respect to thebalance of the kernels in a hardware kernel plane, and to the balance ofthe communication device. Thus, satellite kernel 270 can be activated orbypassed for a given function of an application, depending on the needsand protocol chosen for the application. A description of theconfiguration and operation of a satellite kernel 270 is presented in asubsequent flowchart. The present architecture is well suited to a widerange of data processing functions, operations, and applications besidesspread spectrum communication applications.

In the present embodiment, computing element 273 a includes anarchitecture of electronic devices with coupling arrangements, from oneor more of the possible techniques described in FIG. 2B. That is,depending upon the function, algorithm, operation, or class thereof,being implemented by the hardware kernel, computing element 270 caninclude any combination of the techniques for device choice andconfiguration, including reconfigurable logic 211, reconfigurabledatapath 221, reconfigurable dataflow 231, or reconfigurable logic 241.In the present embodiment, the computing element in a hardware kernel,e.g., computing element 273 a of K1 261 a, can exploit any combinationof the four types of reconfigurability, in an architecture referred toas Dynamically Reconfigurable Logic (DRL). However, the presentinvention is well suited to incorporating other types of computationalmodels that have different levels of granularity or differentapplications of granularity. Additionally, the techniques of FIG. 2Bused in configurable hardware kernel can be chosen depending upon theuncertainty of a design or function within the communication device.Thus, by providing a very flexible architecture to an autonomouslycontrolled configurable hardware kernel for the narrow scope of anuncertain function or algorithmic technique, the present inventionfrugally allocates the most flexible reconfiguration resources. However,the present invention is well suited to complementing these enumeratedtechniques with other configuration and architecture techniques.

Because the computing element 273 a is function (or algorithmic)specific each of the techniques used is subsequently function specific.Thus, the electronic devices and their interconnections can utilizefunction-specific reconfigurable logic 211, function specificreconfigurable datapath 221, function-specific reconfigurable dataflow231 and/or function specific reconfigurable logic 241 techniques asshown in FIG. 2B in one embodiment. The function-specific aspect of thedevices and their interconnects means that the device is only effectiveand useful for the intended function, sub function, or classes thereof,in this embodiment. By doing so, this architecture efficiently deliversa class of MOPS with flexibility in the configuration of these MOPS andscalability across data rates and channel densities.

Electronic devices refer to the basic building blocks of electroniccircuits such as transistors, diodes, resistors, conductors, and otherelements that are well known in the art. The collection of electronicdevices and interconnects can be figuratively divided into a fixedgrouping 275 a and a flexible grouping 275 b, intercoupled to each otheron a device level, as required by the function implemented therein. Forexample, in one embodiment, flexible architecture can be used toselectively group and couple registers to implement a class of functionswhose math operations vary by their bit length, depending on theprotocol used.

Thus, each of the multiple hardware kernels described in FIG. 2C have anarchitecture that is tuned to its intended function. In the presentembodiment, the combination of architecture in a computing element isdependant upon the functions, or class of functions, to be performed bythe hardware kernel. Other variables, such as performance requirements,user preferences, future expandability into undefined protocols are alsoincluded as inputs in the choice of architectures. Because the hardwarekernels each have a discrete function, operation, or class thereof, theycan be evaluated as true object-oriented hardware.

Thus, a channel element can be built-up from the set of configurablehardware kernels to realize a reconfigurable multi-channel digital baseband modem signal path that performs all the digitalmodulation-demodulation as well as channel encoding-decoding requiredper logical channel for all narrowband and wideband telecommunicationstandards. In the present embodiment, kernel plane can form a modem cardin a systematic and modular fashion in modules of multiple channels percard, depending on their radio (cell-site) system planning. The presentinvention can be adapted to accommodate a wide range of channels.

In the present embodiment, two or more types of configurablearchitecture techniques are used in a given hardware kernel. However,the present invention is well suited to using a single type ofconfigurable architecture is used in a given hardware kernel.Additionally, the kernel compositions can vary within a hardware kernelplane, and between hardware kernel planes. Multiple types ofarchitecture can be strategically located and coupled within a hardwarekernel to accommodate the particular variation in the function/subfunction desired. For example, if the variation for sample select subfunction over IS2000, and 3GPP, 3GPP-FDD, 3GPP-TDD, and 1Xtremeprotocols includes the number of bits selected, then the hardware kernelincludes a reconfigurable logic for the interconnect bus and the storagelocation associated with the range of bits and a reconfigurable datapathfor the balance of the circuit.

The present invention is well suited to using a wide range ofarchitectural techniques shown in FIG. 2B, and combinations thereof,from which individual hardware kernels are designed, constructed, andoperated. These hardware kernels are capable of performing a wide rangeof functions within a class that spans a wide range of spread spectrumapplications. Exemplary functions, for which kernels can be configured,are shown in FIGS. 2B, 2C, and 5, and are described hereinafter inAppendix A, entitled “Data Kernel Specification List.”

Several exemplary hardware kernels have been defined in relatedco-pending patent applications and are applicable in the presentcommunication device, e.g., 100 of FIG. 1 b. While these related patentapplications provide a specific function for hardware kernels, thepresent invention is well suited to a wide range of data processingfunctions for electronic devices, such as a spread spectrumcommunication device. These commonly assigned and related applications,which are incorporated herein by reference, include:

-   1) “A CONFIGURABLE CODE GENERATOR SYSTEM FOR SPREAD SPECTRUM    APPLICATIONS,” Attorney Docket No. 9824-0029-888, U.S. patent    application Ser. No. ______, filed on Dec. 28, 2000;-   2) “A CONFIGURABLE MULTIMODE DESPREADER FOR SPREAD SPECTRUM    APPLICATIONS,” Attorney Docket No. 9824-0036-999, U.S. patent    application Ser. No. ______, filed on Dec. 28, 2000;-   3) “A CONFIGURABLE ALL-DIGITAL COHERENT DEMODULATOR SYSTEM FOR    SPREAD SPECTRUM APPLICATIONS,” Attorney Docket No. 9824-0037-999,    U.S. patent application Ser. No. ______, filed on Dec. 28, 2000; and-   4) “METHOD AND APPARATUS FOR PROCESSING A SECONDARY SYNCHRONIZATION    CHANNEL IN A SPREAD SPECTRUM SYSTEM,” Attorney Docket No.    9824-0034-999, U.S. patent application Ser. No. ______, filed on    Jan. 29, 2001, filed herewith.

The term architecture describes the electronic devices and couplingarrangements used in configurable hardware kernel plane 201 a of FIG.2C, Kernel K1 261 a and configurable computation kernel 273 a of FIG.2D, reconfigurable interconnect 204 a of FIG. 2C, and the specificexemplary hardware kernels provided in the aforementioned applications.The coupling arrangements include interconnect routing, grouping, andhierarchy. The various combinations of reconfiguration techniques 211,221, 231 and 241 of FIG. 2B also describe the architecture of theconfigurable computation kernel 273 a, the reconfigurable interconnect204 a, and the specific exemplary hardware kernels. Devices can includecomponents such as gates, selective interconnects, memory, lines, buses,and a wide range of conventional devices that are chosen and coupled inorder to satisfy the functional requirements of a given application.More information on architecture of configurable devices can be found inthe text “Software Radio Architecture,” by Joseph Mitola III, which ishereby incorporated by reference.

Referring now to FIG. 2E, a block diagram of a hardware kernelcontaining a subcomponent hardware kernel is shown, accordance with oneembodiment of the present invention. Hierarchical block diagram 120 bhas many components and coupling arrangements that are similar to thosepresented in FIG. 2D. For purposes of clarity, only a description ofcomponents, coupling arrangements, and alternative embodiments for FIG.2E that are different from FIG. 2D will be provided herein; otherwise,the description of components, coupling arrangements and alternativesprovided in FIG. 2D will apply similarly to the present figure.

Satellite kernel 270 a includes a hierarchy of hardware kernels, whereinanother hardware kernel K7 317 a is included therein. Kernel K7 317 a,having an exemplary configuration as K1 261 a of FIG. 2D, provides adedicated support kernel function to its parent kernel K1 311 a. Anadditional control line 284 a and clock line 279 a is provided todedicated hardware kernel K7 317 a. Due to the hierarchy, dedicatedhardware kernel K7 317 a can step up a clock rate another level for itsown functions if needed for a given application.

Different configurations of a hardware kernel within a hardware kernelcan exist depending on the needs for a given function in a givenapplication. For example, in a spread spectrum application, an exemplarycellular telephony function can tailor parent kernel K1 311 a forperforming a demodulation operation or a matched filter operation.Either of these functions can benefit from a dedicated hardware kernel,e.g. K7 317 a, providing dedicated code generator functions. In thismanner, hardware kernel K7 317 a can run autonomously under the controlof its parent kernel K1 311 a. This configuration and architectureprovides local control and operation, which consequently reduces trafficon a system processor or controller. The present invention is wellsuited to a variety of hierarchical levels or parent hardware kernelshaving different quantities of dedicated kernels therein.

Referring now to FIG. 2F, a block diagram 200 f of the inputs, outputs,and functions accommodated by a hardware kernel in an electronic spreadspectrum communication device is shown, in accordance with oneembodiment of the present invention. Functions described in blockdiagram 200 f represent operation of exemplary hardware kernel(s) ofFIGS. 2C through 2F.

Handshake input 280, input flags 282, and configuration information 281is received at control signal generation block 284. Handshake input 280is a signal from a source outside of a hardware kernel that initiatesthe operation of the hardware kernel, via a control signal generationblock 284. Input flags 282 alter the data, states, or functions of ahardware kernel. For example, a handshake input 280 can enable thehardware kernel functions (or algorithmic computations) 292 to proceed,while an input flag 282 will enable an appropriate communication of aprevious state condition for hardware kernel functions 292. Note thatthe specific conditions, uses, and quantity of input flags can varywidely according to the needs of a particular function in a particularapplication, and the capacity of the hardware kernel functions.Configuration input 281 provides information on how to configurehardware in a hardware kernel so as to perform the desired algorithmcomputation function. Configuration input 281 includes informationspecifying: 1) type of operations to be performed; 2) inputs; 3)outputs; and 4) parameters of the configurable hardware kernel.Configuration input 281 can also include information regarding theinterconnect configuration used to build a cluster, or group, of kernelsfor implementing a function or sub function.

Control signal generation block 284 includes sub functions of preservinge.g., recording, and transmitting a state or a configuration of ahardware kernel as directed by handshake input 280 and configurationinput 281. Control signal generation block 284 also includes a subfunction of clock scaling. Lastly, control signal generation block 284generates output flags 296 and a handshake output 298 to componentsoutside of the hardware kernel. Thus, in the present embodiment, controlsignal generation block 284 provides a control signal, via a bus or amultiplexed line, to algorithm computation function block 292 thatincludes an enabling/status signal 295 c, a state condition signal 295b, and configuration information signal 295 d. Control signal generationblock 284 also provides an adapted clock signal 295 a to algorithmcomputation block 292.

Clock scaling sub function can speed up, slow down, or preserve the rateof the system clock signal 288 received at control signal generationblock 284. The specific rate of the adapted clock signal 295 a dependsupon the rate of data processing for which algorithm computation block292 is designed. Clock signal input 288 is a system clock of thecommunication device in the present embodiment.

In one embodiment, handshake output 298 and output flags 296 indicatethe status of a hardware kernel or of data processed by algorithmiccomputation block 292. For example handshake output 298 or output flags296 include information such as successful execution, error rate, statecondition, etc.

Algorithmic computation block 292 performs a desired algorithm for a setof data, received as input data 290. Inputs 295 b, 295 c, and 295 d fromcontrol signal generation block 284 allows algorithmic computation block292 to essentially perform its algorithmic-specific functionautonomously from the balance of the communication device. During orafter the completion of its function, algorithmic computation block 292provides output data 294 to sources outside of hardware block, andprovides status information 295 to control signal generation block 284for subsequent handshake or flag setting.

Algorithmic computation block can be figuratively divided in to a fixedportion of the algorithm 292 a and a flexible portion of the algorithm292 b, communicating information to each other. The fixed portion block292 a of the algorithm computation is the portion whose algorithmicfunctions essentially do not change for different communicationprotocols, e.g., the core functions or the common math that can beextracted from the different algorithms required for each protocol. Incontrast, the flexible portion 292 b of the algorithm computation is theportion that does change for different communication protocols. In oneembodiment, the fixed portion 292 a and flexible portion 292 b of thealgorithmic computation corresponds to the fixed portion 275 a andflexible portion 275 b of configurable computation kernel 273 a shown inFIG. 2D.

In the present embodiment, function blocks in block diagram 200 f areimplemented by hardware components described in FIGS. 2A through 2F. Forexample, one embodiment implements algorithmic computation function 292of FIG. 2F via computing element 273 a of FIG. 2D, and implementscontrol signal generation block 284 in controller 271 and configurationinformation block 272. Clock signal input 288, handshake input 280, andinput flags 282 are provided to control signal generation block 284 viaconfiguration line 274, and are communicated between components inhardware kernel 261 a via an interconnect line 276, clock line 279, andcontrol line 284. Handshake output 298 and output flags 296 aretransmitted on configuration line 274. Input and output flags, andhandshake input and output, can be provided to/from another hardwarekernel in the hardware kernel plane or to/from components outside ofhardware plane 201 a, via reconfiguration bus 206 a. While the presentembodiment provides specific hardware components and configurations forimplementing hardware kernel functions 200 f, the present invention iswell suited to using a wide variety of hardware components andconfigurations for accommodating locally controlled algorithmic specificfunction blocks.

The present embodiment of components, configuration and functionality ofhardware kernels shown in FIGS. 2B through 2G are capable of providingan operating efficiency from greater than 10 to several hundred (100)MOPS/mW in the present embodiment. This rate is well ahead of what isachievable from a programmable digital signal processor. Yet the presentembodiment also provides a level of flexibility over a wide range offunctions and a level of user control that is well beyond that of atraditional ASIC. The present invention is well suited to deliver a widerange of computation power and computational efficiency, depending uponthe semiconductor process technology, VLSI integration/physical designmethod.

Function Planes

Referring now to FIG. 3A, a functional data flow diagram 300 a forconfigurable multiprocessors in a modem application is shown, inaccordance with one embodiment of the present invention. The connectionsbetween the blocks indicate the spatial connectivity between the groups,while the general layout from left to right is indicative of thehierarchy of operation sequence.

Block diagram 300 a includes a chip-rate processor block 302 coupled toa symbol-sequence processor block 306 and parameter-estimation processorblock 308. Both symbol-sequence processor block 306 and aparameter-estimation processor block 308 are coupled to each other andto a channel-element processor block 310. Data input is first receivedin chip-rate processor block 302 and is output from channel elementprocessor block 310. Specific configurations of hardware kernels thatcan be categorized within each of the processor groups of FIG. 3A,according to their processing rate are described hereinafter.

Chip-rate processor block 302 performs operations at a chip-rate, e.g.,at 1.2288 Mega chips per second (Mcps) as required for an exemplarycommunication protocol. The chip rate implicitly refers to the bit-rateat which data is received at a communication device, e.g., via an analogto digital (A-D) converter. Chip rate processor block 302 includes asegregated component of a code generator unit (CGU) block 304. CGU block304 is explicitly delineated from the chip-rate processor block 302because it can be spatially and temporally shared among multiplechip-rate processing realizations. That is, CGU block 304 can be sharedamong multiple instances of configurable modem processor 102 a of FIG.1B. While the present embodiment refers to a specific numeric rate, thepresent invention is well suited to using any number rate, assuming arelative relationship between the blocks as indicated in FIG. 3A.

Symbol-sequence processor block 306 communicates information betweenchip-rate processor block 302, parameter estimation processor block 308,and channel-element processor block 310. Similarly, parameter-estimationprocessor communicates information from chip-rate processor block 302and channel-element processor block 310.

Hardware kernels can be organized into five classes of signal processingunits, as described in the list below. For example, sample-epoch refersto a kernel capable of performing sample-epoch calculations, and becausethe specification requires this operation be performed at a chip-rate,it is categorized in the chip-rate processor group. The first group is achip-rate processor group, which includes the following functions:Sample-epoch Selector, Multi-standard Despreader; Multi-standardDechannelizer; Code Generation Unit; Integrate and Dump Unit; andMulti-standard Searcher Control. The second group is a Symbol-SequenceProcessor Group, which includes the following functions: TransportFormat Decoder; Dynamic Spreading Factor Computer; Fast HadamardTransform; and Rotator/Squarer. The third group is aParameter-Estimation Processor Group, which includes the followingfunctions: Energy Estimator; Timing Parameter Estimator, and ChannelEstimator. The fourth group is a Channel-Element (multi-finger)Processor Group which includes the following functions:Alignment/Deskewer; Combiner; Soft-decision Computer; InterpathInterference Equalizer, and Receive Antenna Diversity Combiner. Thefifth and final group is a Front-End Group, which includes the followingfunctions: Data Switch Selector; and Sample Interpolator.

The specifications for each of the hardware kernel capabilities areprovided in Appendix A, hereinafter. It is appreciated that one skilledin the art understands the references to CDMA and communication signalvariables and protocols described in Appendix A. Additionally, AppendixA also provides an exemplary sequencing of the modem and codec functionsdescribed therein to realize a variety of transceiver signal paths byconfiguring the kernels and interconnect according to the types ofoperations and dataflow desired.

While the present embodiment provides for the aforementioned specifickernel designations, functions, input, outputs, and parameters, thepresent invention is well suited to including alternative or additionalkernel designations, functions, inputs, outputs, and parameters. Forexample, the present invention is well suited to different communicationprotocols such as time division multiple access (TDMA), or to futureCDMA communication protocols, that are as yet, unspecified. Furthermore,while the present embodiment provides for specific levels of processorrates, the present invention is well suited to using different processorrates, or different relative levels of processor rates.

Referring now to FIG. 3B, an alterative functional data flow diagram 300b for configurable multiprocessors in a modem application is shown, inaccordance with one embodiment of the present invention. The blocks andtheir coupling represent an alternative embodiment to those: presentedin FIG. 3A in which a communication device, e.g., device 100 of FIG. 2,operates.

FIG. 3B provide function blocks (or groups) for both a receive path 354as well as a transmit path 352. The general layout from left to right isindicative of the hierarchy of operation sequence and flow of data forthe Receive path 354 direction. In particular, Receive path 354 includesa front-end processing and storage group 301 coupled to provide data tofinger(s) function block 301 b, to searcher(s) function block 301 c, andto matched filter(s) function block 301 d. In turn, Finger(s) block 301b is coupled to provide data to symbol processor block 301 e and toparameter estimator(s) block 301 f. Symbol Processor block 301 e iscoupled to provide data to channel-element processor block 301 g.Searcher block 301 c and matched filter block 301 d provide feedback tofinger(s) block 301 b via internal software control of communicationdevice 100 of FIG. 1B. Parameter estimator(s) block 301 f providescontrol information to power control lop block 305 which then is coupledto forward processed control information to data mapping block 307 c forregulating data on the transmit path 352.

In contrast, transmit path 352 provides a more linear data flow startingwith a transmit diversity method selection block 307 d coupled toprovide data to data mapping block 307 c. In turn, data mapping blockprocesses data with the input from the power control loop(s) block 305and forwards it to code modulator block 307 b. Lastly, code modulatorblock 307 b is coupled to communicate modulated data to channel summer307 a.

Functional kernels, such as those shown in the subsequent figure, areused to enable each of the functional groups in FIG. 3B. In turn,hardware kernels similar to those in FIGS. 2C and 2D are used toimplement the functional kernels. An example of functional kerneloperation is provided in Appendix A, included herein. This group ofhardware groups allows flexibility in the architecture of the interfaceto the antenna bus, e.g., bus 129 of FIG. 1B. The interface is designedto support both new and legacy equipment via multirate filteringsupporting operation over multiple chip rate inputs

Referring now to FIG. 3C, a block diagram 300 c of several user-definedmodes of operations performed for modem signal processing functions inthe electronic spread spectrum communication device, in accordance withone embodiment of the present invention. The functions are arranged in atime-sequence manner where the output of one function is provided as theinput to the adjacent function. These three modes are exemplary, and thepresent invention is well suited to using a wide variety of functionsequence modes.

Block diagram 300 c includes three separate and distinct user-definedmodes of operation, e.g., a first mode, mode (1) 311, a second mode (2)312, and a third mode (3) 313. In one embodiment, first mode 311corresponds to an exemplary legacy protocol, while user mode (2) 312corresponds to a CDMA 2000 protocol, and user mode (3) 313 correspondsto a 3GPP protocol.

Many functions are common to all three modes. For example, Interpolationfilters 311 a, 312 a, and 313 a are common to all three modes. However,other functions are unique and separate for a given mode. For example,rotate function 312 g and 313 g are not included in mode (1) 311. Theexplicit functions shown in FIG. 3C are as follows:

-   -   User Mode (1) 311 includes: an interpolation filter 311 a, a        sample select function 311 b, a short/long code 311 c, an        integrate and dump (I&D) function 311 d, all of which can be        grouped as a chip-rate functions 314. User mode (1) 311 also        includes: a scale function 311 e, a fast Hadamard transform        (FHD) 311 f, a magnitude (MAG) function 311 g, a deskew function        311 h, all of which can be grouped as symbol-sequence functions        315. Lastly, user mode (1) 311 includes a combine function 311        i, which is a channel-element processor function 318. All the        functions listed for user mode (1) 311 are coupled to each other        in a serial manner.    -   User Mode (2) 312 includes: an interpolation filter 312 a, a        sample select function 312 b, a short/long code 312 c, a        Walsh/Orthogonal Variable Spreading Factor (OVSF) code function        312 d, an I&D function 312 e, a scale function 312 f, a rotate        function 312 g, a deskew function 312 h, a combine function 312        i, all coupled to each other sequentially.    -   User mode (3) 313 includes: an interpolation filter 313 a, a        sample select function 313 b, a short/long code block 313 c, a        Walsh/OVSF function 313 d, an I&D function 313 e, a scale        function 313 f, a rotate function 313 g, an inter-path        interference (IPI) equalize function 313 h, and a combine        function 313 i.

Referring now to FIG. 3D, a block diagram of the modulation/demodulation(modem) functions accommodated by an electronic spread spectrumcommunication device is shown, in accordance with one embodiment of thepresent invention. FIG. 3D illustrates a configurable functional planewith serial and parallel functional capabilities that provide theflexibility, speed and efficiency required accommodating a wide range ofmodem functions for different communication protocols. FIG. 3D alsoillustrates the concept of parallel processing in multiple functionalplanes to accommodate high channel density in a communication system.Exemplary modem functions, for which hardware kernels can be configured,are described hereinafter in Appendix A, entitled “Data KernelSpecification List.” FIG. 3D provides function groups for a Receive path354 only.

The present embodiment of modem function block 320 includes multiplefunctional planes, e.g., functional kernel planes [1] 330 a and [i] 330i that represent the functions required and performed by kernels for agiven application. In the present embodiment, the functions provided arefor an exemplary cellular spread spectrum application. Each functionalplane represents the capabilities of a configurable demodulating fingerhardware kernel plane. While the present embodiment shows only twofunctional planes, the present invention is well suited to using anynumber of functional planes, as appropriate for a given application. Inthe present embodiment, functional planes [1] 330 a through [i] 330 iperform modem functions for any one of a multitude of differentcommunication protocols, e.g., IS2000, 3GPP, as well as anticipatedfuture protocols. While the functions listed in the present embodimentare focused towards CDMA, the present invention is well suited toimplementing functions that are applicable to time division multipleaccess (TDMA) protocol, whose functions are known by those skilled inthe art. The specific communication protocol implemented in a functionalplane depends upon how the functional plane was configured, which isdescribed in a subsequent flowchart.

Functional kernel plane 330 a includes a sequential arrangement 356 d ofsub functions of the modem function that are common to multiplecommunication protocols to be accommodated by a communication device.Functional plane [1] 330 a also includes a parallel arrangement, 356 athrough 356 c, of sub functions that are unique to one or more of themultiple communication protocols. By using this arrangement, the presentinvention can accommodate any of the multiple communication protocolsefficiently, and can quickly change between different protocols. Notethat the specific choice of which functions of the multiplecommunication protocols to include in sequential arrangement and whichfunctions to include in parallel arrangement is a complex task thatevaluates the trade-offs between flexibility, speed, and efficiency ofthe overall architecture of the communication device. In an alternativeembodiment, some functions that are common to different protocols may beincluded in a parallel functional block arrangement.

Sequential arrangement 356 d of sub-functions in functional plane [1]330 a includes the following sub function blocks: 1) interpolationfilter block 331 a; 2) sample select block 332 a; 3) short/long codeblock 334 a; 4) Walsh/orthogonal variable spreading factor (OVSF) block336 a; 5) integrate and dump (I&D) block 338 a; and 6) scale block 339a. Sequential arrangement 356 d of sub-functions represents the commonfunctions that are used in multiple communication protocols. Thus, forexample, WCDMA and some other 3-GPP applications can use thesub-functions listed in sequential arrangement 356 d.

Following scale block 339 a of sequential arrangement 356 d, threegroupings of possible parallel arrangements of functional blocks can bechosen, by flexible coupling 347. Each grouping represents a uniqueconfiguration of functions required by one of multiple communicationprotocols accommodated by the present embodiment. A first grouping 356 aincludes a fast Hadamard transform (FHT) block 340 a followed by amagnitude calculation block 342 a and a deskew/align block 344 a, asrequired for an exemplary communication protocol. A second grouping 356b includes a rotate block 346 a followed by a deskew and align block 347a (that is common between path 356 c and 356 b), as required by 3GPP andCDMA-2000 communication protocol. Finally, a third grouping 356 cincludes a rotate 346 a block (that is common for path 356 b and 356 a)followed by an inter-path interference (IPI) block 349 a, as required bythe 3GPP communication protocol. Each of the three possible groupings,356 a through 356 c, transmits its results to a combining block 350 aassociated with each functional plane. Function blocks 331 a through 339a of sequential arrangement 356 d are common to the extent of theirfunctional category; each function has parameters that can be varied fordifferent protocols that use that function and for changes over time fora given protocol. While the present embodiment of sequential arrangement356 d and parallel arrangement 356 a through 356 c provides a specifictype, quantity, and sequence of functions for a given range ofcommunication protocols, the present invention is well suited to using awide range of functions in each arrangement. Furthermore, the presentinvention is well suited to narrowing or expanding the scope,application, and protocols accommodated by the functions.

In the present embodiment, additional functional planes, e.g.,functional plane [1] 330 a through plane [i] 330 i, include the samefunctions, e.g., interpolating filter block 331 a and 331 i. Thus, everyfunctional plane in modem function block 320 is equally configurablewith the full flexibility to accommodate each of the communicationprotocols. In another embodiment, one or more functional planes havefunctional capabilities that are different from each other. For example,in one embodiment, each functional plane in modem function block 320 hasthe ability to handle different subsets of the superset of communicationprotocols accommodated by the overall communication device. Thus, onefunctional plane can be configured to accommodate IS2000 and CDMA-2000communication protocols, while another functional plane is configured toaccommodate a legacy communication protocol.

Because a functional plane can accommodate multiple communicationprotocols, it is configurable to a desired protocol. On a larger scale,each of the multiple functional planes can be configured to accommodatethe same communication protocols at a given time, or to accommodatedifferent communication protocols at a given time. Thus, for example,functional planes [1] 330 a and [i] 330 i can be configured to bothperform a CDMA-2000 protocol at a given point in time. Alternatively,functional planes [1] 330 a and [i] 330 i can be configured to performdifferent communication protocols at a given point in time, e.g.,functional plane [1] 330 a is configured to perform CDMA-2000 protocolwhile functional plane [i] 330 i is configured for a legacycommunication protocol.

One aspect of the configurabiltiy of a functional plane of FIG. 3D, isthat the configuration itself can change, e.g., it can be reconfigured.The independent variable associated with the change can be time, achannel designation, or some other user-defined variable. The timevariable can be a long or short temporal designation, e.g., years,months, or even milliseconds. Furthermore, the reconfigurability of thefunctional planes is dynamic in one embodiment, e.g., thereconfiguration occurs while other functional planes are operating. Theconfiguration data used to designate the functions and protocolaccommodated may be communicated via wireless transmission ofconfiguration data along with the data, or by loading pre-storedconfiguration data on communication device. In this manner, the presentinvention provides a temporal and functional range of granularity forthe functional planes of the communication device that are definable bya user.

Receive path 354 shows the direction of data flow through functionalblocks 329 through 349 in a modem function plane 330 a. In this manner,the modem function block 320 can accommodate both directions of datatraffic, by time-sharing the functional resources.

In the present embodiment, multiple functional planes, e.g., 330 athrough 330 i, are physically implemented in a single configurable modemprocessor block, e.g., block 102 a of FIG. 1B. As an example, functiongroup A 316 a, which includes FHT function 340 a and Mag function 342 a,and function group B 316 b, which includes interpolation filter 331 a,sample select block 332 a, short/long code 334 a, Walsh/OVSF block 336a, and I & D block 338 a, are implemented in specific subcomponents,e.g., algorithmic-specific kernels, of modem kernel plane 102 a of FIG.1B, as described in subsequent figures. Furthermore, the methods ofconfiguring, selecting, and arranging functions in modem block 320 aredescribed in subsequent flowchart figures. However, the presentinvention is well suited to a wide variety of physical implementationsvia a wide range of methods.

Thus, a channel element can be built-up by the user from the set ofreconfigurable kernels to realize a reconfigurable multi-channel CDMAdigital base band modem signal path that performs all the digitalmodulation-demodulation as well as channel encoding-decoding requiredper logical channel for all narrowband and wideband CDMA standards. Somepossible configurations that a user can realize by configuring thehardware kernels and the configurable interconnect in the communicationdevice are summarized below, for the forward (downlink) and reverse(uplink) links:

-   -   Forward Link        -   1xRTT evolution (IS-2000)—all radio configurations as            described in TIA/EIA IS2000.2        -   3xRTT multicarrier mode        -   3GPP 3.84 MHz Direct-Spread Mode (FDD)        -   ARIB 4.096 Mcps WCDMA    -   Reverse Link        -   1xRTT evolution (IS-2000)—all radio configurations as            described in TIA/EIA IS2000.2        -   3GPP 3.84 MHz Direct-Spread Mode (FDD)        -   ARIB 4.096 Mcps WCDMA

The present modem functional block diagram 320 can be realized byproviding parallel identical channel elements, where each channelelement one or more fingers, for a total number of fingers appropriatefor a given application (e.g., user density, etc.). With each channelelement in receive path 354 consisting of configurable and programmablekernel engines for despreading, demodulating, parameter estimation, andcombining. Modem signal processor function block 320 offers acommunication system with many effective fingers, allowing a very highlevel of channel integration, while allowing the communication system toemploy proprietary algorithms to improve radio link performance, as willbe described hereinafter. Each channel element, including its definitionand structure, is completely under the communication system's controlusing the mixed programming granularity to control dataflow,controlflow, and interconnect. This process is discussed in more detailfor a subsequent flowchart figure.

Transmit path 352 is configured with multiple channel elements in thepresent embodiment, thus enabling maximal use of forward-link capacityper sector in multicarrier systems. The architecture of the modem signalprocessor 102 a of FIG. 1B is such that it enables the system designerto program the chip at many levels, including control of specificdatapaths to realize different algorithms. A hierarchical ApplicationProgramming Interface (API) that supports several levels of user controlfor the modem signal processor is described in co-pending patentapplication entitled “A METHOD FOR DESIGINING A CONFIGURATION FOR ACONFIGURABLE SPREAD SPECTURM COMMUNICATION DEVICE.”

Based on the similarity of the functions across different user-definedmodes in FIG. 3C, the design of configurable hardware kernels can bedetermined, as described in a subsequent flowchart figure. For example,all three of these modes can be configured to run on a singlecommunication device, e.g. device 100 of FIG. 1 b. In the presentembodiment, all three user-modes may appear to exist independent of eachother. However, in reality, a functional implementation of the threedifferent modes can selectively exist on each of the multiple functionalplanes, e.g., function planes [1] 330 a through [l] 220 i, of FIG. 3D.In this embodiment, the similar aspects of all three user modes areincluded in sequential function block 356 d of FIG. 3D, with thenon-similar functional aspects of the three user modes provided in thethree parallel function blocks 356 a through 356 c.

The three parallel function blocks (or paths) 356 a through 356 c ofFIG. 3D can be intermittently selected to provide a sequentially varyingconfiguration protocol within a given functional kernel plane, e.g.,time-sharing the resources. Alternatively, different functional kernelplanes can be configured to different communication protocols dependingupon the communication traffic or user needs. Additionally, differentfunctional kernel planes can be configured to perform different portionsof the functions. For example, functional kernel plane 330 a can be usedto handle all the sequential communication functions 356 d for all threedifferent modes, while functional kernel plane 330 i can perform one ormore of the sequential functional blocks 356 a through 356 c. With allthese scenarios, hardware kernels are used to implement these functionalsequential and parallel blocks, as described in a subsequent figure.

Referring now to FIG. 4, a block diagram of encode/decode (codec)functions accommodated by the electronic spread spectrum communicationdevice is shown, in accordance with one embodiment of the presentinvention. FIG. 3C illustrates a configurable functional plane withfunctional capabilities that provides the flexibility, speed andefficiency required to accommodate a wide range of codec functions fordifferent communication protocols. FIG. 3C also illustrates the conceptof parallel processing in multiple functional planes to accommodate highchannel density in a communication system. Functions in FIG. 4 relate toan exemplary spread spectrum communication system of cellular telephony.

Codec function block 400 includes an address generator block 401 coupledto an allocator function block 402, in turn coupled to dynamicallyassignable scratch/buffer memory 404, such as random access memory(RAM), in the present embodiment. Dynamically assignable scratch/buffermemory 404 is coupled to each of the multiple possible configurabledecoder functional planes. Allocator function block is implemented byallocator hardware block 219 of FIG. 2A, which includes state machinecomponents and memory that is chosen and coupled in a manner to managemultiple functional planes, e.g., planes 406 and 410. The configurationof the allocator components can vary depending upon the protocolimplemented in the multiple functional planes, e.g., planes 406 and 410.Dynamically, a single scratch/buffer memory 404 is operational toprovide configuration and state information as required for configuringand sharing resources in the multiple functional planes 406 and 410.

The present embodiment of codec function block 400 includes a singlefunctional kernel plane for a given data flow direction, e.g., decodefunctional plane 410 for decode data path 258, and encode function plane406 for encode data path 259. Each functional plane utilizesconfigurable codec hardware kernels to accommodate their differentfunctions, which are described hereinafter.

As an illustration, decode functional plane 410 includes an exemplaryarrangement of sub functions for a decode path 408 to translate encodedreceived data into a data signal, per an appropriate communicationprotocol for the desired application. The arrangement of functionsincludes, in one embodiment, a bit field extraction block 410 coupled toa memory block 412, which is then coupled to deinterleaver block 414,which is in turn coupled to rate matching block 416. Rate matching block416 is coupled in parallel to Viterbi block 418 and to Turbo decoderblock 420, both of which are then coupled to provide data to cyclicredundancy checker (CRC) block 422. Lastly, CRC block 422 is coupled tobuffer 424. A similar, complementally coupled arrangement ofsub-functions exists on encode functional kernel plane 406, but isomitted for clarity.

The function blocks provided in FIG. 4 can be implemented oncorresponding individual hardware kernels, e.g., kernel K1 261 a throughK6 266 a. However, some functions may share a common hardware kernel ifthe types of operations (e.g., math operations) and the processing rate(e.g., symbol rate) are similar enough and if scheduling of the hardwarekernel and the data flow through the hardware kernel are satisfactory.

Decode function kernel plane 410 includes other user-configurabledecoder functions, described hereinafter, for convolution decoding andturbo decoding. The basic function of convolution decoding and turbodecoding is known by those skilled in the art. The convolution decoderfunction has the following user-programmable (or user-configurable)parameters: code polynomial; code (R, K), with K=5-9, data rate; blindrate-detection for voice channels; rate matching. Convolution decoderfunction also has user-programmable depuncturing pattern, tracebackmethod, and soft-decision output. Turbo decoder function hasuser-programmable: code polynomials (K=3,4); data rate; block size (upto 6120); number of iterations; termination conditions; decoding metric(max-log-MAP, user-specified correction table); input scaling; tracebackmethod; and depuncturing pattern.

In contrast, encode functional plane 406 includes a sequentialarrangement of functions, or sub functions, (not shown for clarity) foran encode path 409 to translate data into an encoded signal, per anappropriate communication protocol of the desired application. Encodepath 409 shows a data path direction through codec function block 400that is opposite that of decode path 408. In this manner, the codecfunction block 400 can accommodate both directions of data traffic, bytime-sharing the functional resources. A wide range of common functions,implemented serially, and a wide range of diverse functions, implementedparallely, for the wide range of spread spectrum applications can beobtained from the operating specifications for these differentprotocols. In particular, transmit encoder path 409 of FIG. 4 includesuser-configurable encoder kernels for convolution encoding and turboencoding. The following functions make up the encoding kernels:Convolution Encoder function and turbo encoder function; convolutionencoder includes the following user-programmable parameters: codepolynomial (R, K), with K=5-9; rate matching; puncturing pattern. Turboencoder includes user-programmable: code polynomials (K=3,4); data rate;block size; rate matching; puncturing pattern. The specific functionblock descriptions implemented by reconfigurable decoder plane 406include deinterleaver controller, turbo decoder, and convolutiondecoder. Appendix A, provided hereinafter, describes the specificationsfor the decode and encode functions implemented in the hardware kernels.It is appreciated that one skilled in the art understands the referencesto CDMA and communication signal variables and protocols within AppendixA.

The Channel Codec function plane 400, as implemented in Channel CodecSignal Processor 104 of FIG. 1B, operates under the following criteria,in one embodiment:

-   -   A maximum of 32 logical channels are available per carrier per        configuration    -   A configuration, as defined as a radio channel configuration,        maps directly onto one thread of processing on the Channel Codec        Signal Processor    -   Type of channel specified by BTS channel card controller.    -   Multiple radio channel configurations must be supported across a        multiple standards, including all radio configuration        characteristics for the reverse channel in derivative systems        (Radio Configurations 1-6) as well as ARIB and 3GPP        Direct-Spread FDD (Radio Configurations based on Service Class        and Associated User Data Rate).    -   BTS Channel Card Controller will interface to the BTS Cell        Controller for sending and receiving control information        associated with call setup, teardown, and handoff.    -   The BTS Cell Controller will not demand a grand total of channel        bandwidth beyond the capacity of the Channel Codec Signal        Processor(s). If this cannot be guaranteed, then a protocol on        dropping channels beyond the capacity limit must be specified.    -   Assignments for radio configurations for specific channels will        be made prior to the arrival of the frame; i.e. assignments for        FRAME (N) will be sent prior to the arrival of FRAME (N).    -   The logical channel assignments for a physical channel (for the        BTS) can be changed during the course of a call at any FRAME        boundary.    -   Physical channels may request a larger bandwidth or smaller        bandwidth for the same assignment during the course of a call.    -   Logical channel assignments will be maintained so there are no        holes in the assignment table. This provides the capability for        adding the largest (widest) new channel assignment within the        remaining capacity.    -   Channel assignments and deassignments require one time slot        (only one assignment or deassignment per time slot). This        assumes cleanup occurs upon every assignment/deassignment.    -   Resource consolidation/defragmentation will be performed        immediately after a deassignment or assignment.

While the present embodiment shows only two functional planes, thepresent invention is well suited to using any number of functionalplanes, as appropriate for a given application. In the presentembodiment, functional planes 406 and 410 can be configured to performcodec functions for a wide range of spread spectrum communicationapplications, as described hereinabove. For example, in one embodiment,multiple functional planes (not shown) for both encoding and/or decodingcan exist. In the present embodiment, additional functional planes for agiven data flow, e.g., decoding path 408, include the same functions fordecoding. Thus, every functional plane in codec functions is equallyconfigurable with the full flexibility to accommodate each of thecommunication protocols. In another embodiment, one or more functionalplanes have functional capabilities that are different from each other.For example, in one embodiment, each functional plane in codec functionblock 400 has the ability to handle different subsets of the superset ofcommunication protocols accommodated by the overall communicationdevice. Thus, one functional plane can be configured to accommodateIS-95 and CDMA-2000 communication protocols, while another functionalplane is configured to accommodate WCDMA and 3GPP. All the functionalplanes can be physically implemented in a single codec hardwareprocessor block, e.g., block 104 of FIG. 1B, in the present embodiment.However, the present invention is well suited to a wide variety ofphysical implementations. The configurabiltiy and dynamicreconfigurability of codec functional planes is also described insubsequent flowcharts.

Referring now to FIG. 5, a diagram of the separating and combiningprocess of a single thread into multiple concurrent threads to beaccommodated on the communication device is shown, in accordance withone embodiment of the present invention.

The model for computation using the reconfigurable multiprocessorarchitecture of the present invention starts from the model of a singlethread representing Function A 504, which is initialized on amicroprocessor or digital signal processor, e.g., processor 112 of FIG.1B. Several application-specific processing threads, e.g., thread 1 501through thread 3 503, are split off in the pre-processing stage. Forexample, in one embodiment, function A 504 is a modem function within agiven application, e.g., a wireless communication protocol such as CDMAIS-95. Function A 504 includes multiple sub functions that can beperformed in series or in parallel.

The sub functions that are performed concurrently, e.g., in parallel,are referred to as a threads, e.g., thread 1 501, thread 2 502, andthread 3 503, for the modem function A 504. The number of threads canvary in different embodiments, according to the operations required by agiven function or sub function, and their need to be performedconcurrently, e.g., defined by a communication protocol in the presentembodiment. Concurrent operations 508 are performed on each of therespective threads 501-403 in a communication device, according to thesub function requirements. Thereafter, the threads are terminated withthe provision of data and control is returned the microprocessor. Eachthread can be implemented on an autonomous configurable kernel in thepresent embodiment. A processor 112 along with an optional allocator219, as shown in FIG. 2A can initiate or manage the separating andcombining operations.

The chronological sequence of events for the function of separating andcombining functions/sub functions is provided in a subsequent flowchartfigure. In one embodiment, a modulation function can be broken down intoconcurrent sub function on data, such as interpolation filter, sampleselect, short/long code generation, etc. Similarly, each sub functionscan be broken down into multiple concurrent operations. For example, afilter interpolation requires operations such as data fetch, addition,decision logic, etc.

Flowchart Implementation of Processes

Referring now to FIG. 6A, a flowchart 6100 of the process used toimplement a design configuration onto a configurable spread spectrumelectronic spread spectrum communication device is shown, in accordancewith one embodiment of the present invention. By using the flowchartembodiment of the present invention, a configurable electronic devicecan be configured to a user-specific design configuration. In thismanner a significant amount of control over the operation and functionof the configurable device is provided to the user. The implementationof the design into the device is direct and convenient, thus providingtimely flexibility in a field where protocols can change quickly andfrequently. Flowchart 6100 is implemented, in general, by communicationdevice 100 of FIG. 1B and VMI 150 of FIG. 1D, as well as diagrams ofcomponents as shown in FIGS. 2A through 2G.

Flowchart 6100 begins with step 6102. In step 6102 of the presentembodiment, a design configuration is received at a configurable device.For example, a design configuration for a configurable communicationdevice can be a 3GPP-specific configuration, implemented byuser-specified proprietary algorithms, in one embodiment. Additionaldescription on the process for designing a configuration for aconfigurable device is provided in co-pending patent applicationentitled “A METHOD FOR DESIGINING A CONFIGURATION FOR A CONFIGURABLESPREAD SPECTURM COMMUNICATION DEVICE.”

Step 6102 is implemented, in one embodiment, by providing designconfiguration data, e.g., from configuration mappings input 174 of FIG.1D, to configuration information block 272 of a hardware kernel K1 261 avia reconfiguration bus 206 a. More than one configuration can beprovided in one embodiment. In this case, a configurable device can bepartitioned to perform multiple protocols, having a unique configurationfor one or more functions, within a single communication device. Thepartitioning can be static amongst the hardware, or can be dynamic,e.g., in the case of time-shared configurable hardware kernels. Theconfiguration information can also contain information to provideoptions, e.g., quality of service (QOS) when implementing the functionfor a given user or channel in the communication device. Thetransmission of the design configuration can either be via wired orwireless coupling.

While the present embodiment for step 6102 provides a specific locationof configuration information block 272 and a specific route, e.g.,reconfiguration bus 206 a, in which it is downloaded to a hardwarekernel, the present invention is well suited to using alternativecomponents and interconnects to implement step 6102. By providing theconfiguration information at a level that is local, e.g., in terms ofspatial and control aspects, to the individual hardware kernel, thepresent embodiment provides effective local processing that isautonomous, in varying degrees, to the balance of the host device. Inthis manner, the present invention is able to provide efficient andflexible parallel processing of data.

Step 6102 can be implemented by receiving desired configurations forhardware kernels, e.g., kernel 261 a of FIGS. 2C through 2F, incommunication device 100 of FIG. 1B, via a variety of embodiments. Forexample, in one embodiment, configuration information is received viawired communications with a computing device, e.g., a workstation. Inanother embodiment, configuration information can be provided by anelectronic storage medium, e.g., CD-ROM. In yet another embodiment,configuration information is received by wireless transmission fromanother communication device via antenna 120. Furthermore, configurationinformation is provided at the time communication device 100 ismanufactured and/or initially programmed for operation in the field, inthe present embodiment. However, in another embodiment, configurationinformation is dynamically implemented at a time communication device100 is in operation in the field. Configuration information is received,processed, and implemented via system processor 112 (or BTS cardcontroller 110 a) and system memory 118, which then communicates theinformation and instructions via bus, e.g., bus 127 of FIG. 1C, toconfigurable processors, e.g., configurable modem processors 102 a and102 b and configurable codec processor 104. Within the configurableprocessors, local memory, e.g., configuration memory 272, and localcontroller, e.g., controller 271 of FIGS. 2D and 2E, can controlimplementation of configuration information to, and operation of,hardware satellite kernels, e.g., satellite kernel 270, in the presentembodiment. Following step 6102, flowchart 6100 proceeds to step 6104.

In step 6104 of the present embodiment, design configuration software(s/w) is loaded into control registers. Step 6104 is implemented, in oneembodiment, by storing design configuration data in configurationinformation block 272 of the appropriate hardware kernel. Cardcontroller 110 a or processor 112 of communication device 100 in FIG. 1Bcan direct the configuration information to the appropriate controlregister addresses within configuration information block 272 of FIG. 2Das identified by an off-line mapping operation, e.g., a programminginterface (or programming tools) on a separate workstation. In thismanner, a hardware kernel designed for integrate and dump functions willreceive the configuration software information related to integrate anddump functions.

Steps 6104 and 6102 can be implemented by receiving a computer programwith data and instructions for configuring the configurable spreadspectrum electronic communication device. Exemplary computer programsfor configuring modem and codec functions in the configurable spreadspectrum electronic communication are provided in Appendix Bhereinafter. The exemplary computer programs provide an implementationfile that defines a modem finger function by defining: the sequence ofoperations; the parameters that control the dataflow; and the parametersthat control the initiation or termination of the function. Thus, aspecific finger behavior is realized below by building the finger usingthe principle of an extensible data type. The sequence of operationsthat define a finger are determined by the user, and then declared asthe finger type. The user then declares the parameters that will controlthe dataflow and then define the initiation and termination conditions.It is appreciated that one skilled in the art can interpret the computerlanguage specific syntax provided in this examples of Appendix B. Thisexample demonstrates how a user can realize a specific level of controlover the functional operation of the hardware kernels. Thus,controllability, observability, and new configurations and behaviors canbe realized via using the extensible data types of the presentinvention. Thus the present invention overcomes limitations associatedwith the static prior art configuration for communication devices.

The configuration data and computer program having instructions toimplement the configuration data are implemented by a virtual machineinterface (VMI), in the present embodiment, that quickly and efficientlytranslates the computer language information to the appropriateconfiguration mappings. FIG. 1D provides an exemplary VMI 150 forinterfacing configurable components, e.g., configurable modem processor120 a and configurable codec processor 140 of configurable communicationdevice 100, as shown in FIG. 1B. In particular, I/O device driver block166 contains the respective drivers for the algorithmic-specifichardware kernels (or satellite kernels) described in FIGS. 2C through2G. For example, if hardware kernel block K1 261 a through K6 266 a ofFIG. 2C have architectures that are designed for demodulation functions,then the necessary drivers for each of these hardware kernel blocks willexist in I/O device drivers block 166. These drivers will be used toconfigure the hardware kernels and implement the desired functions.Device drivers can exist for all the functions covered by a givenapplication, e.g., for communication device 100 of FIG. 1B. FIG. 1Dprovides additional description of the VMI operation. Following step6104, flowchart 6100 proceeds to step 6106.

In step 6106 of the present embodiment, an operating system interface isloaded into a controller. Step 6106 is implemented, in one embodiment,by receiving the operating system interface, as determined by aconfiguration design process. The controller receiving this informationcan range from: BTS card controller 110 a of FIG. 1B; BTS cellcontroller 114 of FIG. 1C; allocator (controller) 219 of FIG. 2A; andthe individual hardware kernel controllers, e.g., controller 271 of FIG.2D, in each of the hardware kernel planes, e.g., plane [1] 201 a throughplane [i] 201 i.

In particular, BTS Channel Card Controller 110 a (or an optional DSP)hosts the software stack developed by the user, e.g., per aconfiguration design process for a configurable device, that includes astandards-driven OSI Layer 1 Modem software stack. This softwarecontrols the operation of a modem signal processor, e.g. configurablemodem processor 102 a, and a Channel Codec Signal Processor, e.g., codecprocessor 104. This software stack exploits the full power of anApplication Programming Interface (API) for the wireless spread spectrumcommunication platform to realize efficient radio link performance foreach channel via a user's proprietary signal processing techniques. Inthis manner, the present embodiment effectively employs a hierarchy ofcontrollers for providing configuration information and controlinformation that will allow the autonomous operation of the individualhardware kernels. This allows for efficient parallel processing, withthe benefit of reconfigurability. Following step 6106, flowchart 6100proceeds to step 6108.

In step 6108 of the present embodiment, the operating system (OS)interface is linked with the API. Step 6108 is implemented, in oneembodiment, by linking the appropriate set of interfaces from the API,e.g., from API inputs 172 of FIG. 1D. The OS interface data and the APIinputs can be stored in memory 118 on communication device. Step 6108effectively reconciles the two interfaces such that the OS of thecommunication device can implement the functions desired on theappropriate hardware kernels, as provided in a configuration designprocess. Following step 6108, flowchart 6100 ends.

Referring now to FIG. 6B, a flowchart 6200 of the process used tooperate a configurable spread spectrum electronic spread spectrumcommunication device is shown, in accordance with one embodiment of thepresent invention. By using the flowchart embodiment of the presentinvention, an application with different protocols can be provided forin a configurable electronic device. Consequently, the present inventionprovides a method for designing efficient and intelligent flexibilityinto a configurable device to accommodate current differences andprotocol as well as future protocol changes. Flowchart 6200 isimplemented, in general, using the functional block diagram of FIG. 1Dand the hardware block diagrams of FIGS. 1A through 1C, and FIGS. 2Athrough 2F.

Flowchart 6200 begins with step 6202. In step 6202 of the presentembodiment, a signal is received at a configurable electronic device forprocessing. Step 6202 is implemented, in an uplink transmission from amobile to a BTS, by a communication device, e.g., device 100 of FIG. 1B,receiving a signal via wireless radio frequency (RF) transmission. Thesignal can be a continuous signal, as appropriate for CDMA systems, or asignal having time-divided packets therein, as appropriate for TDMAsystems. And the sending and the receiving devices could be a basetransceiver station (BTS), a mobile unit, or a test platform.Furthermore, the signal can include data information, controlinformation, configuration information, and options for implementingconfiguration information. In particular step 6202 is implemented in oneembodiment by receiving signal on antenna 120 and communicated by bus129 to communication device 100, as shown in FIG. 1B.

In a downlink embodiment for step 6202, a MTSO traffic interface sendsvoice, data, and control data packets, via bus 128 to thetransmit-data-pump path in CDMA BTS Modem Platform communication device100 according to the configuration specified by the BTS Cell Controller114 for that specific payload, as shown in FIG. 1B. In an uplinkembodiment for step 6202, the communication device 100, under controlfrom the BTS Card Controller 110 a, assigns a signal source to areceive-data-pump path in the modem signal processor. Following step6202, flowchart 6200 proceeds to step 6204.

In step 6204 of the present embodiment, the signal is preprocessed. Step6204 is implemented, in one embodiment, by performing preprocessingsteps that prepare a signal for the core processing to be performed bythe reconfigurable hardware kernels of the communication device. Forexample, in a downlink scenario, one embodiment of step 6204 includespreprocessing steps such as disassembly of the signal andsynchronization of signal with over the air timing. Pre-processing canalso include demuxing and sector-by-sector combining in the cases wherechannels from different sectors arrive from different modem signalprocessor transmit paths. In an uplink scenario, one embodiment of step6204 includes parallel steps of synchronizing the signal and providingdifferent types of data for the subsequent processing and transmission.By preprocessing the signal, it is prepared for the scope of processingavailable to a given hardware design kernel. Following step 6204,flowchart 6200 proceeds to step 6206.

In step 6206 of the present embodiment, a configuration for aconfigurable element is determined for a given user/channel. Asmentioned in step 6104, the configuration can be user/channel specific.Thus, the configuration can include inputs such as radio type 6207 a orquality of service (QOS) level 6207 b, to determine the appropriateconfiguration of the user/channel, or to determine the specific optionwithin an appropriate configuration. Radio type of service 6207 a caninclude IS-95B, IS-95C, and IS-2000 as described in TIA/EIA IS2000.2.This input can also include the choice of 3GPP x3.84 MHz Direct-SpreadMode frequency division duplex (FDD) communication protocol. QOS level6207 b can be a contracted level of reception quality or optionalservice features. While specific input types and choices are provided inthe present embodiment, the present invention is well suited to usingany type of input, and choice therein, as is supported by the design ofthe configurable device.

Step 6206 is implemented in one embodiment using memory 118, BTS cardcontroller 110 b of communication device 101 in FIG. 1C, or by usingallocator 219 of FIG. 2A and configuration information block 272 of FIG.2D. In one embodiment, a physical channel can be tied to a specifiedconfiguration, and thus established a priori. Alternatively, the data tobe processed by the configurable device can contain header informationthat indicates a protocol, and hence an appropriate configuration forthe hardware kernels assigned to process that protocol. Following step6206, flowchart 6200 proceeds to step 6208.

In step 6208 of the present embodiment, the signal is assigned a datapump path on one or more independent processors. Step 6208 isimplemented, in one embodiment, by allocator 219 and/or microprocessor112 of FIG. 2A, in conjunction with memory. Microprocessor 112 andallocator 219 use a unique set of communication primitives to indicatethe data pump path between multiple hardware kernels of which the datais required to flow for data processing that will satiate the desiredfunctions. The information needed for a data pump path includes thehardware kernel addresses from which, and to which, data flows for therequired data processing operation. The information also includes anyconfiguration data necessary for the reconfigurable interconnect, e.g.,interconnect 204 a of FIG. 2C, to realize the interconnection of the twoor more hardware kernels. The address, instructions, and configurationinformation (such as reconfigurable interconnect configuration) arestored in memory 118 of communication device 100 of FIG. 1B and/ormemory portion of configuration information block 272 or in controllerblock 271 of a given hardware kernel as shown in FIGS. 2D and 2E.

As an example related to step 6208, several function blocks, e.g., forfunction group B 316 b of FIG. 3D, can be implemented on hardware kernelplane 201 a of FIG. 2C. In particular, hardware kernel group A 268 a ofFIG. 2C can utilize hardware kernels K1 261 a, K4 264 a, and K5 265 a,with the appropriate interconnects between them being established byreconfigurable interconnect 204 a to implement a given function, orgroup of functions. The data pump path refers to the hardware kernelsused to implement the functions, and the sequence of data flow betweenthese appropriate kernels. Following step 6208, flowchart 6200 proceedsto step 6210.

In step 6210 of the present embodiment, design configuration informationis received at a configurable hardware kernel for processing arespective portion of the signal. Step 6210 is implemented, in oneembodiment, by receiving design configuration information fromconfiguration information block 272 at satellite kernel 270, within thehardware kernel 261 a, as shown in FIG. 2D. Alternatively, the memorylocation of the information can be provided elsewhere, such as a memoryportion of allocator 219. This information is downloaded in the presentembodiment at start up of the device, following an off-power conditionthat cleared memory in satellite kernel 270. Alternatively, thisinformation can be reloaded for an interrupt or fault condition, aspreset or determined by a user. New configuration information can bereceived while the device is powered up, thus overriding the previousconfiguration. Functional block diagram 200 f shows that control signalgeneration block 284 provides a configuration information function viacommunicating the configuration to algorithmic computation block 292 vialine 295 d. Following step 6210, flowchart 6200 proceeds to step 6212.

In step 6212 of the present embodiment, an inquiry determines iftime-sharing is occurring. If time-sharing is occurring, then flowchart6200 proceeds to step 6214. However, if time-sharing is not occurring,then flowchart 6200 skips to step 6216. Step 6212 provides the logic todetermine whether a configurable device has a time-share set up or not.The time-share set up requires additional management and memory storagesteps, as indicated hereinafter. A configuration input 121 to acommunication device can indicate whether time-sharing is used or not,and to what extent it is used. Step 6212 is implemented, in oneembodiment, via allocator 219 or processor 112 of FIG. 2A. Inparticular, allocator 219 or processor 112 can be used to determinewhether time-sharing exists, e.g., via pre-programmed time-shareconfiguration of a channel ID or some other identifier. Furthermore, aconfiguration design process provides the necessary configurationinformation and management logistics to implement a time-sharing set up.

Time-sharing, per step 6212, can exist on a wide range of hardwarelevels. For example, time-sharing can exist on a hardware kernel byhardware kernel basis, e.g., K1 261 a, or on a hardware plane byhardware plane basis, e.g. hardware kernel plane 201 a. Furthermore,time-sharing can occur intermittently on a device, as programmed by auser. For example, a device can time-share in terms of temporalvariation, e.g., different parts of the day require more or lessresources, or spatial diversity, and e.g., some sectors of a basestation having higher resource requirements than other sectors. Byproviding scaled clock speeds to discrete hardware, e.g., hardwarekernels, and by providing a selectable quantity of resources, e.g.,hardware kernels, the present invention provides effective scalabilitywithout significant changes to the architecture. Additional informationon time-sharing apparatus and processes is described in co-pendingpatent application entitled “IMPROVED APPARATUS AND METHOD FORMULTI-THREADED SIGNAL PROCESSING,” Ser. No. 09/492,634, and filed onJan. 27, 2000. This related application is commonly assigned, and ishereby incorporated by reference.

Step 6214 arises if time-sharing is desired, per step 6212. In step 6214of the present embodiment, the state information for the applicable timeslice is received. Step 6214 is implemented, in one embodiment, byretrieving a stored state of configurable computation kernel (orconfigurable satellite element) 273 a in a memory portion of controller271, or in configuration information block 272, of FIG. 2E or 2Drespectively. Furthermore, the state of the reconfigurable interconnect204 a of FIG. 2C can be stored in memory in allocator 219, as shown inFIG. 2A, or in memory 118 of communication device 100, in anotherembodiment. The state information is provided to configurable computingelement 273 a. In particular, the type of state information is thatrequired for performing the operation for a given function. Thus, in oneembodiment, the states in registers used for filtering can be stored.Likewise, the state of the data being processed can be stored, if theoperation was not complete. Following step 6214, flowchart 6200 proceedsto step 6216.

In step 6216 of the present embodiment, the signal is processed by theappropriate configurable elements, e.g., the hardware plane or hardwarekernel, etc., as shown in FIGS. 2A through 2F. In practice, after theAPI functions are executed on the processor per step 6204, control istransferred, e.g., via a handshake protocol, to the pool ofreconfigurable kernels, e.g., K1 261 a through K6 266 a of FIG. 2C. Bytransferring control, a lower level of controller now has control withinthe controller hierarchy system.

Step 6216 is implemented in the present embodiment on one or morehardware kernels, e.g., kernel K1 261 a, which has autonomous localizedcontrol to control an operation to completion. In this manner, thepresent embodiment provides a data processing island that conservessystem resources by performing its operations locally, in areconfigurable and/or time-share manner. Step 6216 is enabled, in oneembodiment, by allocator 219 of FIG. 2A directing the appropriate datasignal and control signal to the configurable computation kernel, e.g.,configurable computation kernel 273 a, as described in ‘data pumpassignment’ step 6208. FIG. 2 f shows the input/output interfaces andfunctions that enable step 6216. For example, input data 290 is receivedat algorithmic computation block 292, along with state information 295b, and other types of data such as adapted clock signal 295 a andenable/status 295 c that enable the algorithmic computation block. Theinterfaces and functions described in FIG. 2 f are implemented inhardware in FIGS. 2A through 2F.

In the present embodiment, the functions implemented in step 6216 forcommunication device 100 of FIG. 1B are the modem functions 6216 a andthe codec functions 6217 b. In particular, modem functions for adownlink scenario include encoding, interleaving, channelization codemixing, I/Q scrambling code mixing, transmit diversity processing,filtering, and rate-dependent scaling. Modem functions for uplinkinclude: despreading, dechannelization, demodulation, and combining, asprogrammed by the Layer 1 software stack, including facilities toperform multipath and antenna diversity combining.

In contrast, the codec functions implemented for step 6216 for adownlink scenario include: encoding, interleaving, channelization codemixing, and I/Q scrambling code mixing, transmit diversity processing,filtering, and rate-dependent scaling. The codec functions for uplinkscenario include despreading, deinterleaving, channel decoding, assemblyof payload data and control information for MTSO. The Data KernelSpecification List, described in Appendix A, provides a more technicaldescription of exemplary discrete sub functions needed to accomplish themodem and codec functions. However, the present invention is well suitedto implementing a wide range of functions in a hardware kernel, suitablefor a given application. The modem signal processor, under control fromthe BTS Card Controller, assigns a signal source to a receive-data-pumppath in the modem signal processor. The modem signal processor, undercontrol from the BTS Card Controller, assigns a signal source to areceive-data-pump path in the modem signal processor. Following step6216, flowchart 6200 proceeds to step 6218.

In step 6218 of the present embodiment, the signal is post processed.Thus, after the pool of reconfigurable kernels, e.g., K1 261 a throughK6 266 a of FIG. 2C, have completed their operations on the data, thencontrol, or computations, are returned back to the processor.Consequently, this completes the circle of hierarchical controlsimplemented by a return handshake. Step 6218 is implemented, in oneembodiment, providing signal to subsequent downstream or upstreamfunctions and devices that prepare the signal for the application, e.g.,transmission of a signal via antenna, amplification of a signal forreception, etc. In particular, post processing for a downlink scenariofrom a BTS can include generating multiplexed I/Q digital base bandwaveforms identified with a channel, sector, and/or antenna tag. Anotherpost processing step includes formatting the composite signal,consisting of all the signals on a per-carrier and per-sector, asnecessary and sent from the channel card to other signal conditioningcircuits in the base-station for digital to analog (D/A) conversion andfor radio frequency (RF) transmission. Following step 6218, flowchart6200 ends.

The present embodiment applies flowcharts 6100 and 6200 to a digitalwireless communication system. However, the present invention can beapplied to a wide range of applications and a wide range of deviceconfigurations. Within the wireless communication system described inthe present embodiment, the present invention is applicable to mobileunits, base stations, and test platforms.

While flowcharts 6100 and 6200 of the present embodiment show a specificsequence and quantity of steps, the present invention is suitable toalternative embodiments. For example, not all the steps provided inflowcharts 6100 and 6200 are required for the present invention. Inparticular, flowchart 5200 provides steps 5212 and 5214 for a time-sharescenario for hardware kernels. However, the time-scenario is optionalfor the present invention, and thus, these steps may be omitted in oneembodiment. Similarly, other steps may be omitted depending upon theapplication. In contrast, the present invention is well suited toincorporating additional steps to those presented, as required by anapplication, or as desired for permutations in the process.

Lastly, the sequence of the steps for flowcharts 6100, and 6200 can bemodified depending upon the application. Thus, while flowcharts 6100 and6200 are shown as a single serial process, they can also be implementedas a continuous or parallel process. For example, is appreciated thatflowchart 6100 can be repeated for the multiple hardware kernel planes,e.g., plane 201 a of FIG. 2C, in the multiple processors, e.g.,processors 102 a and 102 b of FIG. 1B, within a communication device,e.g., device 100.

Many of the instructions for the steps, and the data input and outputfrom the steps, of flowcharts 6100, and 6200 utilize memory andprocessor hardware components, e.g., memory 118 processor 112 of FIG.1B. The memory storage used to implement the flowchart steps in thepresent embodiment can either be permanent, such as read only memory(ROM), or temporary memory such as random access memory (RAM). Memorystorage can also be any other type of memory storage, capable ofcontaining program instructions, such as a hard drive, a CD ROM, orflash memory. Similarly, the processor used to implement the flowchartsteps can either be a dedicated controller, an existing systemprocessor, or it can be a dedicated digital signal processing (DSP)processor, as appropriate for the type of step. Alternatively, theinstructions may be implemented using some form of a state machine.

Some portions of the detailed description, e.g., the processes, arepresented in terms of procedures, logic blocks, processing, and othersymbolic representations of operations on data bits within a computer ordigital system memory or on signals within a communication device. Thesedescriptions and representations are the means used by those skilled inthe digital communication arts to most effectively convey the substanceof their work to others skilled in the art. A procedure, logic block,process, etc., is herein, and generally, conceived to be aself-consistent sequence of steps or instructions leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these physicalmanipulations take the form of electrical or magnetic signals capable ofbeing stored, transferred, combined, compared, and otherwise manipulatedin a communication device or a processor. For reasons of convenience,and with reference to common usage, these signals are referred to asbits, values, elements, symbols, characters, terms, numbers, or the likewith reference to the present invention.

It should be borne in mind, however, that all of these terms are to beinterpreted as referencing physical manipulations and quantities and aremerely convenient labels to be interpreted further in view of termscommonly used in the art. Unless specifically stated otherwise asapparent from the following discussions, it is understood thatthroughout discussions of the present invention, terms such as“receiving,” “generating,” “mapping,” “repeating,” “identifying,”“translating,” “dividing,” “decoding,” “defining,” “time-sharing,”“scheduling,” “assigning,” “creating,” “categorizing,” “loading,”“interfacing,” “disassembling,” “performing,” “synchronizing,”“demuxing,” “transmitting,” “combining,” “formatting,” “assembling,” orthe like, refer to the action and processes of a communication device ora similar electronic computing device, that manipulates and transformsdata. The data is represented as physical (electronic) quantities withinthe communication devices components, or the computer system's registersand memories, and is transformed into other data similarly representedas physical quantities within the communication device components, orcomputer system memories or registers, or other such informationstorage, transmission or display devices.

In view of the embodiments presented herein, the present inventioneffectively provides a method and apparatus that can effectivelyaccommodate the increases in the quantity of users and the quantity ofdata transferred using the limited frequency bandwidth. Furthermore thepresent invention provides a solution that overcomes the limitations ofprotocol non-uniformity and proliferation in the wirelesscommunications. The limitations of cost and burden associated withchanges in versions or performance levels of a communication protocolare also resolved by the present invention. In an effort to minimize therisks and maximize the rewards, the present invention substantiallyshortens the lead-time and the investment required for implementing anew specification. Finally, the present invention provides veryreasonable power consumption for the communication device.

The foregoing descriptions of specific embodiments of the presentinvention have been presented for purposes of illustration anddescription. They are not intended to be exhaustive or to limit theinvention to the precise forms disclosed, and naturally, manymodifications and variations are feasible in light of the aboveteaching. The embodiments were chosen and described in order to bestexplain the principles of the invention and its practical application,to thereby enable those skilled in the art to best utilize the inventionand various embodiments with various modifications as is suitable to theparticular use contemplated. It is intended that the scope of theinvention be defined by the claims appended hereto and theirequivalents.

1-16. (canceled)
 17. An electronic device having a discrete processorarchitecture, the communication device comprising: a first computingelement for performing a first discrete operation, or portion thereof,in an application; a second computing element for performing a seconddiscrete operation, or portion thereof, in the application; and areconfigurable interconnect coupled to the first computing element andthe second computing element, wherein the first computing element, thesecond computing element, and the reconfigurable interconnect areoperable to perform a class of functions within an application.
 18. Theelectronic device recited in claim 17, wherein the first computingelement and the second computing element are heterogeneous with respectto each other in terms of programming granularity.
 19. The electronicdevice recited in claim 17 wherein the first computing element and thesecond computing element are heterogeneous in terms of levels ofmillions of operations (MOPs) capacity.
 20. The electronic devicerecited in claim 17 further comprising a scheduler state machine coupledto the first computing element and to the second configurable element,the scheduler state machine sequencing the first discrete operation ofthe first computing element and the second discrete operation of thesecond computing element in parallel or in series to implement thefunction.
 21. The electronic device recited in claim 17 wherein thereconfigurable interconnect has an uncommitted architecture.
 22. Theelectronic device recited in claim 17 wherein the reconfigurableinterconnect has a restricted amount of interconnections between thefirst computing element and the second computing element, the restrictedamount of interconnections proportional to a variation within the classof functions in the application.
 23. The electronic device recited inclaim 17 wherein the reconfigurable interconnect couples a quantity ofinput/output lines from the first computing element with a quantity ofinput/output lines from the second computing element in a manner that isdefined by a rule set, the rule set representing a communicationprocessing function.
 24. The electronic device recited in claim 17wherein the reconfigurable interconnect is a programmable bus channel.25. The electronic device recited in claim 17 wherein the reconfigurableinterconnect has a reconfigurable logic configuration.
 26. Theelectronic device recited in claim 17 wherein the reconfigurableinterconnect is reconfigurable on a temporal basis, a logical basis, ora functional basis.
 27. The electronic device recited in claim 26wherein the reconfigurable interconnect has a plurality ofconfigurations that couple the first computing element and the secondcomputing element, the plurality of configurations of the reconfigurableinterconnect varying in time.
 28. The electronic device recited in claim17 wherein the first computing element and the second computing elementcan operate in a plurality of modes.
 29. The electronic device recitedin claim 17 wherein the class of functions is for a modem function in awireless communication application.
 30. The electronic device recited inclaim 17 wherein the class of functions is for a codec function in awireless communication application.
 31. The electronic device recited inclaim 18 wherein the first computing element, the second computingelement, and the reconfigurable interconnect are configurable to performa specific function defined within the class of functions of theapplication.
 32. The electronic device recited in claim 17 furthercomprising a plurality of computing elements, wherein each of theplurality of elements have at least one line selectively coupled to thereconfigurable interconnect.
 33. The electronic device recited in claim31, wherein the class of functions is based upon a level of performancefor the application.
 34. The electronic device recited in claim 33,wherein the level of performance is a symbol-based level of performance.35. The electronic device recited in claim 33, wherein the level ofperformance is based on millions of operations per second (MOPS). 36.The electronic device recited in claim 33, wherein the level ofperformance is based on a type of mathematics for the application.37-98. (canceled)